Home Original page

PEP 236: Back to the __future__

Tim Peters tim.one at home.com
Tue Feb 27 13:14:30 EST 2001 
[posted & mailed]

[PEP 236]
>     From time to time, Python makes an incompatible change to the
>     advertised semantics of core language constructs, or changes their
>     accidental (implementation-dependent) behavior in some way.

[Konrad Hinsen]
> I am not at all happy with this approach. Incompatible changes should
> not happen "from time to time", but as rarely as possible and then all
> at the same time.

The PEP doesn't address either the frequency or nature of incompatible
changes, it's defining a mechanism to help people deal with incompatible
changes *when* they occur.

> I much preferred the "Py3K" project which was to include all the
> improvements that had to be held back due to compatibility concern.

Incompatible changes have been made with virtually every Python release since
before 1.0.  The changes are *usually* so minor and affect so little code
that few people notice them in practice (for example, how many people were
burned by introducing "lambda" as a new keyword?  IIRC, none -- but that was
an incompatible change!).  Still, Python has more users all the time, and a
mechanism to ease transitioning to even minor changes has value in proportion
to the megalines of code out there.

As to P3K, there's no funding for a rewrite from scratch.  So, barring a
miracle, Python evolves incrementally, and it wouldn't remain Python unless
it does so in ways that keep the language clean.

> Like many Python users, I have a huge base of installed code, lots of
> it written by myself, but the majority written by others. Everything
> works fine together, and I am happy and productive.

And you've managed to do that despite a decade of incompatible language
changes already.  Why *assume* the future is going to be so much worse than
the past?  Perhaps because it hasn't happened yet <wink>?

> Now comes Python 2.1 with nested scopes. I don't expect much of my own
> code to break, but I can't be sure,

It won't break in 2.1, but you'll get warnings about fishy cases in 2.1, and
the __future__ stmt will let you know for sure and change such code at your
convenience.

> I certainly didn't write it with a possible change of scoping rules in
> mind.

Note that most of the few cases of nested-scope breakage *known* so far
actually had nothing to do with nested scopes at heart:  they had to do with
code violating the Lang Ref's prohibition against using "import *" at other
than module scope.  Such code was always undefined.  Jeremy is bending
backwards 167 degrees to make that code still work in the same way it worked
by accident (and in violation of the language spec) whenever possible.

> So perhaps I'll have to modify it a bit, that shouldn't be much work.

The purpose of PEP 236 is to make that easier for you than it would have been
otherwise.

> But then there's all the code from others that might also break, and
> that I don't want to fix at all. And since some of my code will depend
> on code from others, I won't fix my own code either and stick to
> Python 1.5 instead. Which in turn forces others who depend on my code
> to do the same. Sure, sooner or later everybody will want to use the
> new features of Python 2.1. But by then Python 2.1 will have been
> replaced by 2.2, with its own set of incompatible changes.

This would carry more weight if it described a new phenomenon -- but you got
to 1.5.2 via a long series of incompatible-in-small-ways releases before
1.5.2.  It's just business as usual.  Perhaps you jumped on the train at
1.5.2?  Many did, and they've enjoyed the illusion of 100% stability simply
because no update (not even sorely needed bugfix patches) to 1.5.2 was
released for about 18 months.  But 1.5.2 was an historical anomaly, not the
norm.

Still, if you're happy with 1.5.2, stay with it!  You won't be forced to
upgrade.  Perhaps if enough people get burned by "Guido intends to break two
lines of code pointed out in a warning message!" <0.9 wink>, some entity will
arise to keep 1.5.2 alive forever.

> If, on the other hand, incompatible changes occur only every five
> years or so, then people will be inclined to install two Python
> distributions in parallel and update their code over a period of a few
> months.

PEP 236 aims to let them update their code, incrementally (one module at a
time), over a period of about half a year, and without needing to install two
Python distributions in parallel.  We're trying to make staying current
easier.

> Moral: incompatible changes should happen on a time scale compatible
> with uncoordinated collective code development, which is years, not
> months.

As the PEP said, it's aimed at people who intend to keep current.  I believe
it will be a real help for them.  As the PEP also says, people who don't want
to keep current have harder problems, which the PEP doesn't even pretend to
address.

BTW, the only way to avoid all incompatible changes is to avoid fixing bugs
too:  over the years, and regardless of language, I've had much more of my
code break due to accidentally relying on buggy or undefined behavior than
due to deliberate changes in correctly implemented defined behavior.

the-only-reliable-stability-is-death-ly y'rs  - tim
More information about the Python-list mailing list