might compatibility become a *goal*?

[David LeBlanc]

Backwards compatability is a good thing - but not if it's at the expense of
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

> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Greg Weeks
> Sent: Friday, May 17, 2002 9:29
> To: python-list at python.org
> Subject: might compatibility become a *goal*?
>
>
> Python is not backward compatible.  New versions of python don't work with
> 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
> --
> http://mail.python.org/mailman/listinfo/python-list