[I should perhaps note that *exact* backward compatibility isn't a
reasonable goal for Python. For example, increasing the visibility of
nested scopes breaks the following code:
def f(a):
def g():
print a
g()
try: f("hello")
except: print "bye"
In 1.5.2, "bye" is printed. In 2.1, "hello" is printed. But this is an
absurd example, where the programmer achieves an effect with deliberate
perversity. Putting such goofy code aside, I suspect that backward
compatibility is a reasonable goal.]
Backward compatibility does not seem to be a goal of the controllers of
Python. (Is that just Guido?) Indeed, lack of backward compatibility
seems to be an expected "feature" of Python, given the introduction of the
__future__ module. 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. I
for one would feel happier if that was the case. Is that a feasible goal?
Does anyone else think it might be worthwhile?
no longer complaining about TIMTOWTDI,
Greg
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
Maybe it would be a good idea to create a utility for Python that looks at
code and reports anachronisms. Part of PyChecker perhaps? Even better and
more challenging is something that can refactor the code on the fly - that
most certainly is left as an exercise for the reader! :-)
David LeBlanc
Seattle, WA USA
Probably not quite what you were thinking of, but:
http://sourceforge.net/projects/bicyclerepair/
--
Skip Montanaro (sk...@pobox.com - http://www.mojam.com/)
"Excellant Written and Communications Skills required" - seen on chi.jobs
Huh? This statement alone makes me feel like discounting your entire
post.
Neil
But that was a backward-compatible change.
Greg
This would be an option only if A) I never shared code with others, B)
others never shared code with me, C) my current Python verision was
bug-free, and D) Python developers promised to port my old version to the
new machines and operating systems I'll be using in the future.
Greg
Hmmm. The purpose of __future__ is to soften the introduction of
backward-incompatible fieatures, is it not?
Greg
I covered this in my previous reply; a combination of "you get what you
pay for" and "you can't have your cake and eat it too". In a nutshell: the
Python team appears to value backwards compatibility as well as valuing
other things, but obviously they have to sometimes make the best decision
they can (sometimes breakage is good in the long run).
There are plenty of ways for you to get closer to what you want, but if
none of them include you stepping up and lending a hand (e.g. backporting
bug fixes for all to enjoy), it hardly seems reasonable to complain about
the Python team's allocation of scarce resources (at the very, very least
you could cite specific examples of breakage and how you would have
handled it better, but even that's not very helpful).
-Dave
I think for this discussion to be useful, you need to distinguish
between the meanings of "backwards compatibility" and be specific
about any changes that have bothered you.
-Tom Loredo
regards Gerrit