PEP Parade

[Joshua Macy]

Chris Gonnerman wrote:

> Yeah, but "major" language standards change every few years... Python
> releases come about 1-2 per year.  We have to resist the urge to change
> something major in the core too frequently.
> 


   The standards may only change every few years, if you don't count 
Java as a "major" language, but all the vendors of implementations for 
those languages I've ever dealt with release patches at the rate of 1-2 
per year, or more frequently.  Even the COBOL vendors.  And every patch 
release that fixes something stands a chance of breaking something else 
(even if only code that worked around the old improper behavior).  Shops 
that really care about that and have no viable regression test strategy 
upgrade less frequently, and if they ship software make sure that they 
ship exactly what's needed to run their product (no easy task on 
Windows, thanks to dll hell).  My experience is that shops that take the 
conservative approach (even mainframe shops) eventually end up throwing 
out working systems because the exact compiler version that they rely on 
fall off the vendor's support list and it becomes too painful to upgrade 
through multiple releases.  And in Microsoft shops insult is added to 
injury when you have to pay to upgrade to something that will break your 
existing code.

   But nobody is holding a gun to your head and saying "upgrade or 
die"--and unlike with closed source compilers, if you're bound and 
determined never to move off 1.5.2 you have the source code so you can 
continue to maintain it unto as-yet-undreamed-of platforms and 
architectures.  Equally true is that nobody is likely to agree to do 
this maintenance for you for free.

As for me, I've yet to see a change to Python since 1.5.2 that I regard 
as "major" in terms of incompatibility with existing, working code 
(plenty of new features for what used to be invalid syntax) that you 
didn't have to explicitly enable with a __future__ statement, and in 
that case there was a whole release in between where you could test with 
either behavior.

I can understand people taking a more conservative approach, but then I 
lose them when they say they should build a sub-community around the 
inviolability of a particular old release.  And do what?  Sit around 
looking at the old source code and say "Yep, we're not going to change 
that"?  The obvious approach to me is that if you're not prepared, for 
whatever reason, to upgrade: don't upgrade.  If you are serious about 
distributing a stable working system: distribute the whole system, 
interpreter and library included.

   Joshua