Instead of using encode/decode is it better to use str2bytes and
bytes2str, so that the types in Python 2 are unchanged. More important,
this prevents the double encoding of bytes, which causes problems
when they have non-ASCII data encoded.

Errors were being raised for returning `None` in Python 2
(due to a missing else branch) and for re-encoding bytes
in Python 2.

I changed the code to use str2bytes in the cases where bytes
are expected.

An unicode encoding error was being raised in
test_AccountingTransaction_getListBoxColumnList_item_column in Python 2,
when the `html` variable was being passed to the `StringIO`
constructor. The error was only reproducible when running the tests in
the CLI.

The problem was that we were using cStringIO module in Python 2, and the
string فارسی (farsi) appears in the HTML (probably inside a language
picker). cStringIO cannot parse unicode characters that are non-ASCII.
The solution is to use "six.StringIO", which uses the (slower,
but unicode-compatible) StringIO module in Python 2.

( I'm wondering if we need this patch at all on py3 )

__getitem__ was missing causing unsubscriptable-object on BTrees

so that Tester methods will have some __roles__ as Getter.

because str(float) result is different between py2/py3.

* py2
>>> str(-0.8999999999999999)
'-0.9'

* py3
>>> str(-0.8999999999999999)
'-0.8999999999999999'

with ROUND_DOWN, we have a different behaviour between py2/py3, that caused failures in
erp5_simplified_invoicing:testTradeModelLine.

Here is what happened in _round(1.9999999999999998) in
bt5/erp5_simulation/DocumentTemplateItem/portal_components/document.erp5.FloatEquivalenceTester.py

* py2
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('2.000000')
(because str(1.9999999999999998) is '2.0')

* py3
decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN')
=> Decimal('1.999999')
(because str(1.9999999999999998) is '1.9999999999999998')

But ROUND_DOWN result of 1.9999999999999998 with 0.000001 precision should be 1.999999 thus py2 behaviour is wrong.

nexedi/erp5!1751 (comment 203735)

On python2, attributes of new style classes (classes, not instances)
were not properly validated. On python3, attributes of classes were not.

In current versions, sorted is allowed in RestrictedPython.

Also, our implementation of sorted was not correct with generators,
it consumed the generator by iterating on it a first time to check the
values.

Run zope with ERP5_COMPONENT_OVERRIDE_PATH set to a : separated list of
path containing components files to load components from files instead
of portal_components.

This can be used to repair zope after a bad edit of component.

This scenario does not really seem important, in such a scenario, first
repair the broken class (typicallly, by fixing the business template
dependency so that the business template containing the broken class is
updated first)

for pylint 3 to understand erp5 dynamic modules