[Python-ideas] from __past__ import division, str, etc

[Chris Angelico]

On Thu, Jan 9, 2014 at 1:57 AM, Alejandro López Correa <alc at spika.net> wrote:
> I am thinking both in language syntax like division behaviour, unicode, str,
> etc, and major library changes.

The point of the __future__ directive is to enable per-module changes,
which are applied at compile-time. The __future__ features spanning
the 2.x / 3.x gap are:

division (changes the meaning of an operator)
absolute_import (changes the way modules are searched for)
print_function (ditches some language magic in favour of a function)
unicode_literals (changes the meaning of unadorned quoted strings)

In theory, division and unicode_literals could probably be the targets
of a from __past__ directive, but there's little point. Change the
code now, use the directive, and then when you move to 3.x, the
directive does nothing. (The other two would be more of a problem - I
doubt the code to make print a statement exists in Py3, and the
complete rewrite of the import machinery would make old-style
importing dubious. In any case, you probably don't want old-style
importing.)

The unicode and str (or str and bytes) types have been the subject of
some other discussions here on python-ideas, so I recommend reading up
on those threads; I won't try to reopen the discussion here. There've
been quite a few suggestions made, several of which could be quite
viable without even requiring interpreter changes.

Library changes are definitely not something you'd want a "from
__past__ import" statement for. That would be exceedingly messy.
However, there are a number of wrapper modules that let you bury the
2-vs-3 differences; instead of importing module X_name_1 or module
X_name_2, you simply import X from wrapper, and it'll automatically
give you the one you need. That at least covers the cases where the
APIs are the same and it's just the names that differ. When anything
more than that has changed, it wouldn't be possible to use a
per-module flag (as "from __future__ import" is) to change that
anyway.

Once you feel the push to change interpreters and execute the code
under Python 3, it's best to make your code run properly under Py3,
rather than try to hold onto the past. Straddle the gap by continuing
to run a Py2 interpreter and progressively changing your code to use
__future__ print_function and division, and to get the text/bytes
distinction clear, and then the jump to Py3 will be way easier.

ChrisA