might compatibility become a *goal*?
Greg Weeks
old code. (The redefinition of "/" is an example of this.) My hunch is
that C, C++, and perhaps even Perl are considerably more backward
compatible than Python.
[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
bru...@tbye.com
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
David LeBlanc
hobbling the language! Languages, spoken or computer, evolve or die. Cobol,
Fortran, Java, C, C++ have all evolved in incompatible ways from their
initial offerings. It's been my (limited) experience that old python code
runs on new python releases at the worst with minimal glitches that are
obvious and easily changed to conform with the newer language feature(s).
OTOH, there have been changes in some of the other languages that have been
considerably worse to deal with: the change in formal paramter lists in C
functions being an excellent case in point. Going and adding type specifiers
to formal argument lists in a large C program taketh long and paineth arse.
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
Skip Montanaro
David> Even better and more challenging is something that can refactor
David> the code on the fly - that most certainly is left as an exercise
David> for the reader! :-)
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
Neil Schemenauer
> Indeed, lack of backward compatibility seems to be an expected
> "feature" of Python, given the introduction of the __future__ module.
Huh? This statement alone makes me feel like discounting your entire
post.
Neil
Greg Weeks
: considerably worse to deal with: the change in formal paramter lists in C
: functions being an excellent case in point. Going and adding type specifiers
: to formal argument lists in a large C program taketh long and paineth arse.
But that was a backward-compatible change.
Greg
Greg Weeks
: You can make and achieve that goal now: don't upgrade.
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
Greg Weeks
Hmmm. The purpose of __future__ is to soften the introduction of
backward-incompatible fieatures, is it not?
Greg
bru...@tbye.com
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
Tom Loredo
My impression, as a heavy user since 1.5.2, is that the Python dev
crew have bent over backwards to maintain backward compatibility
in the sense of having old code run under new versions, and have
also been very cautious and conservative regarding adding new
features that would prevent new code from running under old versions.
Having watched the discussion surrounding many of these choices
over the past 3 years or so, I have to say that I am extremely
impressed by the insight and wisdom shown by the developers as
a community. Sometimes it has taken me a while to appreciate
their reasoning, but I can't think of a case where I didn't
come to agree with them, if not immediately, then at least after
living with the change a while.
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
GerritM
news:3CEE88FB...@astro.cornell.edu...
provide any useful insight. Only specific objectives and specific actual
(versus academical) problems provides insight in seemingly conflicting
interests and often result in creative and elegant solutions (although some
compromises creep in).
regards Gerrit