Why not python-future

[guettli]

Hi,

The tool futurize from Python-Future seems to do roughly the same thing as python-modernize.

It would be very nice, if you could explain the difference (pros and cons).

At the moment it is hard to choose the right tools for new comers.

[takluyver]

Fair question. Both are built on the code-modifying machinery created for 2to3.

Modernize is relatively conservative: it places more weight on not breaking code that works on Python 2, while trying to do most of the routine work for Python 3 compatibility. It often adds imports of the six compatibility library.

Futurize takes a more aggressive approach: it tries to produce more idiomatic Python 3 code, using the rest of the stuff in python-future to help that code run under Python 2.

[ngie-eign]

For some projects, it's easier to sell having backwards compatible code to others (say, release managers) using six, as opposed to the python future library. Example: a project I work on added six package support to previous project versions and it's easier to make changes work with python-modernize instead of futurize.

I agree, however, that it's more optimal to pick one tool and stick with it, instead of using both.

[jayvdb]

echoing @ngie-eign , "six" has literally been a part of Django until v3, so adding a dependency on six is a no-brainer for keeping Django apps alive. future is heavier, more intrusive, and not something you want to be adding to Python 3 if you can avoid it. (Django 3 removes django.utils.six, but immediately after PyPI package django.utils.six appears to re-instate it ;-) )

[guettli]

I created this issue several years ago. If you use modern python/django this does not matter any more.