Where can I find documentation of Python-Future imports that are incompletely implemented?

Question

I recently discovered that the round function available in future does not support negative digit rounding, which is incompatible with builtin round :

>>> from builtins import round
>>> round(4781, -2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/future/builtins/newround.py", line 33, in newround
    raise NotImplementedError('negative ndigits not supported yet')
NotImplementedError: negative ndigits not supported yet

This somewhat limits the usefulness of the Python-Future quick-start recommendation:

The easiest way is to start each new module with these lines:

 from __future__ import (absolute_import, division, print_function, unicode_literals) from builtins import * 

Then write standard Python 3 code.

I can't find the round incompatibility documented anywhere, and wonder what other functions or types behave differently or have non-implemented features. What other gotchas are there? Where are these incompatibilities documented?

Answer 1

There is no such list.

The Python-Future project is entirely separate from the Python project, so you indeed won't find any implementation gaps in the Python-Future project listed in the official Python documentation.

It is unfortunate that the reference documentation for round() fails to mention this gap in the implementation. An oblique reference to the newround module docstring isn't helpful either, as it too is very scant on details .

You'll have to ask the Python-Future project for such a list, you could try to file an issue to ask them to make such a list.

In the intervening time, you could search for NotImplementedError references in the source code. This will yield an incomplete list, as there may be short-comings in the implementation not covered by raising that exception.

---

On a personal note, I would recommend against using Python-Future; the project's philosophy of backporting everything without regard for suitability or performance is ill-suited for production code; for example, their super() implementation has to rely on full scans of all attributes on the class MRO to locate the relevant class to use as the first argumant, making it slow and cumbersome. Just because you can make it work somehow doesn't mean you should.

That their implementations are incomplete without clear indication where the gaps are only makes it harder to change my view on the project.