might compatibility become a *goal*?

[brueckd at tbye.com]

On Fri, 17 May 2002, Greg Weeks wrote:

Hi Greg,

> Python is not backward compatible.  New versions of python don't work with
> old code.

Isn't that a bit broad? Much of my 1.5.2 code still works just fine, and 
the stuff I upgraded to 2.0 worked through 2.1 and is quite happy on 2.2.

> Backward compatibility does not seem to be a goal of the controllers of
> Python.  (Is that just Guido?)

Please be specific. Upon what, exactly, are you basing this? My impression 
is that reasonable steps are taken to remain backwards compatible (it _is_ 
a goal), but obviously (and thankfully!) not at all costs. It *seems* that 
when the choice is made to break compatibilty, it's the result of 
evaluating the costs versus the benefits, e.g. feature X is likely to 
break some code but not much, but it would remove a real wart from the 
language, and removing it now is much less painful than later.

Java and C might appear to be more backwards compatible, but that's just a 
fallacy - they are pretty much stagnant languages; a new version of Java 
is a new version of the VM, of the supporting libraries, etc., but rarely 
a change in the language itself. Goodness, and even that doesn't guarantee 
anything; consider the heyday of Java AWT's 1.0 to 1.1 transition!

> On the other hand, if enough people wanted backward
> compatibility, it might be possible to make it a goal that, say, all
> Pythons after 3.0 will be backward compatible with (nongoofy) 3.0 code.

You can make and achieve that goal now: don't upgrade. Or, since the
Python team is using CVS which lets you see change history, you could
volunteer your time by back-applying bug fixes and back-porting new
modules to the version of your choice. If you're not willing to do that,
then it doesn't make sense to be too unhappy with their choice of
allocating very finite resources.

> I for one would feel happier if that was the case.  Is that a feasible
> goal? Does anyone else think it might be worthwhile?

Define "worthwhile". For me the current level of code breakage is pretty
low (or my tolerance is pretty high) - a lot of my deployed apps ship with
their own version of Python anyway, and/or I purposely don't upgrade some
applications/boxes until I need to. So far it's been pretty simple:  
install new Python, run test suites, fix problems if any, deploy. The 
single biggest block of time I _ever_ spent on breakage was changing stuff 
like s.connect('10.20.30.40',500) to s.connect(('10.20.30.40',500)), and 
that was literally on the order of minutes, not days or even just hours 
(if I remember right the bulk of it was fixed with a massive search and 
replace on 'connect' and 'append').

> no longer complaining about TIMTOWTDI,

?? Seems pretty orthoganal to backwards compatibility, no?

-Dave