Backwards Compatibility of Python versions

[Paul Rubin]

"Steve Holden" <sholden at holdenweb.com> writes:
> > > > If I type "3//4" into 1.5.2 or 2.1, I get a SyntaxError exception, so
> > > > it isn't backwards compatible.
> > > >...
> > Yes, but they DON'T continue to run, then the new release DOESN'T provide
> > backwards compatibility.
> 
> But surely your example above is about asking 1.5.2 or 2.1 to do a "//"
> operation? Anyway, we can omit all further discussion on *that* topic since
> it's clearly not what's foremost in your mind.

The absence of // in 1.5.2 and 2.1 just shows that importing future division
doesn't provide backwards compatibility.  I suggested an alternate way
to provide it, namely giving 3.0 a way to import "past" division.

> Only because you've already decried *the* forward-compatible alternative:
> 
> 3) Use divmod()[0]
> 
> You said "yerch" (or something similar to this), but surely from an
> engineering point of view it gets the pragmatic result you want.

Of course it doesn't.  It discards what are supposed to be among
Python's main virtues--readability, conciseness, and ease of
understanding.  Those are pragmatically nothing to sneeze at.
Just last night I sent some Python code to a Lisp weenie, saying
basically "look how cool Python is".  Can you understand how stupid
it would have looked, if I'd had to say divmod(x,y)[0] every time
I wanted integer division?

> Tim admitted this as a remote possiblity rather than suggesting it was
> probable. As in "there's nothing to stop anyone doing it". Certainly 2.1.2
> is the most stable release, but it doesn't implement the current Python
> language, whose definition is now implemented by the 2.2 release.

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).

> Indeed. So just write in the forwards-compatible subset of 1.5.2,
> and your problem goes away.

I do try to do that, but if it means avoiding using division and who
knows what else, it gets to be a big pain.  

> > home, but if I was installing a new production system today, I'd use
> > 2.1.1.
> 
> I'd use 2.1.2, but I presume you've just overlooked this January 16 release.
> I must be missing something. 

I thought the Jan 16 release was 2.1.1--I must have gotten confused.  Sorry.

> If I'm not using 2.2 features, I have no need to switch. So, surely,
> if I *want* to use those features then I will switch regardless of
> the inconvenience.

I don't know what the best approach to that is.  I think I'd rather let
2.2 age a little while longer before doing anything important with it.

> Aah, "for general distribution". In that case, you are stuck with either
> remaining in the forwards-compatible 1.5.2 subset, or distributing the
> interpreter with your applications. We can probably agree that while the
> latter is practical for large applications (via py2exe of the McMillan
> installer, or in the same way Zope does), for smaller programs it simply
> carries too much overhead. But I see you wanting the best of both worlds.

I'm not sure what you mean about the best of both worlds.  Python's
"advertising" itself as a mature language to me means there should not
be a useable 1.5.2 subset that keeps shrinking, as long as 1.5.2 usage
is still widespread.  If it's an experimental research language, fine,
keep tweaking and changing it, but don't advertise it as being mature
or production-ready without understanding that that means supporting a
lot of legacy code.  Trying to do both (attract a broad userbase by
claiming maturity, yet also feel free to break existing code by
changing the language at whim) is closer to what I think of as the
poor sense of wanting the best of both worlds.  GCC (a production C
compiler) takes a more responsible approach--it implements language
changes sometimes, but supports legacy programs through compiler flags
like "-traditional".

> > That is a problem too.
>
> But a (relatively) minor one. RedHat have stuck with 1.5.2 for
> rather longer that was strictly necessary for Anaconda support, they
> could have updated it relatively easily but presumably backed off
> for engineering reasons.

I wonder what the demographics really are (what percentage of users
are using what Python version).  If not many are still using 1.5.2
then I can stop worrying about it, but 2.1 is definitely still in the
mainstream.

> > 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").
> >
> Because Guido doesn't feel it will be good for your sanity.

He said that?  The subject has come up before?  I didn't notice
anything about it in the PEP, so I was thinking of entering it as a
request in Sourceforge.