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