PEP 236: Back to the __future__

[Tim Peters]

[Konrad Hinsen]
> Indeed. I have been using Python since 1.3 and never had to change a
> single line due to language changes, and only very few lines due to
> library changes (regular expressions).

Then you're not aggressive enough in visiting Python's dark corners <wink>.

[Erik Max Francis]
> The only changes I've had to make was what amounts to the bugfix with
> the socket address names (e.g., socket.connect((host, port)) instead of
> socket.connect(host, port)).

This is one I'm sure we would have used __future__ for, if __future__ had
existed.  Guido made a convincing case (to me, anyway) that it was a bug in
the interpreter that it allowed the latter form, and the docs didn't flatly
contradict him <ahem>.  But the docs weren't clear enough, and some instances
of the broken form were in the standard distribution.  That made it painful
to say "oops!  we're taking it away now":  despite that taking it away was
the right thing to do, we knew for certain it would break existing code
(under CPython; IIRC, JPython wasn't deluded on this point).  In a
__futurized__ world, you would have gotten a release in which both forms
worked, with warning messages about the broken form.

Hmm.  Bad example <wink> -- this one really has nothing to do with __future__
after all.  It has to do with that there *is* a mechanism for producing
warnings now (we couldn't warn before just because there was no machinery
*to* produce warnings!).

> And, of course, taking advantage of 2.0 features such as list
> comprehensions.

__future__ wouldn't get involved in those either, because those new features
were wholly backward compatible.  __future__ is only for the rare changes
that may break some existing code (changes to the scope rules in the presence
of nested functions is the only example we have for 2.1; and that in *some*
of those cases, we're going to start enforcing the Ref Man's long-standing
restrictions on the use of "import *").

not-that-people-shouldn't-panic-anyway-ly y'rs  - tim