ACCEPTED: PEP 285

[Thomas Bellman]

James Logajan <JamesL at Lugoj.com> writes:

> Sorry, I meant to use "major" here as in "there are new features or 
> semantic changes in this release that if you use in your code, it wont run 
> at all or as you expect on previous releases". Doesn't matter what you call 
> it, if a 2.1 script can't run at all or as expected on 2.0, that is a major 
> change in the _colloquial_ sense. I consider the nature of the changes 
> between so-called "minor" releases and their frequency a major problem to 
> _me_. I don't think you can realistically "argue" those problems away. I am 
> hoping that you will try to accommodate my experiences into your Python 
> world view before brushing them off.

I think your world-view is broken.  If a program uses new features
in a release, or even just assumes the bug-fixes in that release
to be present, then the program *obviously* won't work the way it
was intended if you run it in a release old enough to *lack* those
features or bug-fixes.  It doesn't matter if those new features
involve the introduction of static typing, if it's a new library
module not present in the older release, a new function, or just
fixing a bug so that Python behaves as documented.  The program
which is written assuming those new features, won't work in a
Python version old enough to not have them, irregardless of how
small the changes are.

If your definition of a minor release is that no program written
for that new release will behave differently when run on the
previous release, then it is a useless release, because it changes
*nothing*, it does not even fix bugs.

100% *forward* compatibility can only be achieved by not changing
anything at all.


-- 
Thomas Bellman,   Lysator Computer Club,   Linköping University,  Sweden
"God is real, but Jesus is an integer."      !  bellman @ lysator.liu.se
                                             !  Make Love -- Nicht Wahr!