Backwards Compatibility of Python versions

[Tim Peters]

[Paul Rubin]
> ...
> What does "nothing to stop anyone doing it" mean?  Maybe Tim can explain
> that.  If I make some patches to 1.5.2 and submit it to the maintainers
> as 1.5.3, will they release it on the python.org website?  What if
> I make patches to 1.2 and submit it as 1.2.1?  (Or 1.2.2 or whatever).

The "Bug Fix Releases" PEP covers this, as has been pointed out before:

    http://python.sourceforge.net/peps/pep-0006.html

Nobody has time to look at "some patches", whether they're for a 1.5.2 or a
2.2 bugfix release.  Someone has to volunteer to do what the PEP says,
namely create a maintenance branch under CVS and get everything ready except
for final packaging.  Assuming it's you, if Guido can be persuaded there's
enough interest in the maintenance release you've created to justify the
work (meaning enough interest to justify dropping or delaying other current
work), he'll direct the PythonLabs crew to finish the release (including
publishing on python.org, the whole bit).  Else you'll have to.  Note that
during the time you've announced you're responsible for a given bugfix
release, it's your job to review patches people may submit for it, and to
either test them yourself across all platforms, or find enough other
interested volunteers to do it for you.  It's real work.

> ...
> I wonder what the demographics really are (what percentage of users
> are using what Python version).

Nobody knows.

> ...
> I don't see at all why some mechanism can't be provided to turn off the
> change ("import from past") just like there's now a mechanism to turn on
> the change ("import from future").
> ...
> The subject has come up before?

Is there a subject that hasn't <wink>?  If Guido had any plan to do this, it
would be mentioned in the PEP.  FWIW, I predict with high confidence he
won't go for it.  He's trying to change the language forever, not provide
for incompatible dialects based on goofy pseudo-imports; __future__ was only
designed to ease one-way transitions, and it's part of the design that every
__future__ statement eventually has no semantic effect; __past__ didn't even
get off the ground.