We seem to see this issue a lot here and perhaps the problem stems
from the fact that there's no really experimental branch (or at
least I don't know about it :) ) to python where the cutting edge
people can mess with the cutting edge and won't feel too bad if they
get burnt. Perhaps Python should adopt a versioning number such
that major changes occur during odd numbers, etc. Just so users
have an idea what's coming. Add a minor version number and release
more minor versions. That way we can always expect major changes
between them and at least everybody was *always* warned, as opposed
to downloading the latest version and praying that something you
liked wasn't depreciated, a warning was received or that something
might break. Maybe that might help identify how to document the
major changes, or rather when users should look and see what has
changed/what has broken, etc.
I think the backwards compatibility is pretty damn good though. I
had no problems writing an app and backporting it to 1.5.x (I
basically just had to use the string module). I did use functional
stuff over list comprehension though... My next app, however, will
require python 2.x and that's an audience decision. But not every one
has that luxury.
Almost an after thought, the last thing we want is to take the
Java route though and have 'classes' disappear and new ones replace
them with new interfaces. python's uniformity was one of the biggest
sellers to me. Ugh.
-- Mike
On Tue, May 28 @ 16:49, Guido van Rossum wrote:
> > As an aside, note that this backward compatibility is actually a
> > mixed blessing, because it means you don't have to update your
> > modules now, but there will come a time when it is going to bite
> > you.
>
> When new releases take features away, we will issue warnings as a
> gentle push. When they add features, I don't know why you *should*
> use the new features, unless you need them -- and then you have your
> motivation in your needs.
>
> > As a personal example: the MacPython toolbox modules haven't
> > been updated to make use of the GC stuff yet (and that's been
> > there since 2.0, no?),
>
> But the API was totally changed for 2.2, so you're actually lucky that
> you didn't do it for 2.0. ;-)
>
> > let alone the new type system. And these
> > are almost all generated, so it would probably only take a few
> > dozen lines of code to fix them. And the new type system would
> > be a real boon for some of the modules (such as the windowing
> > and dialog stuff), but because there's no real push (i.e.
> > everything still works) nothing has happened yet...
>
> I don't think *anything* can be done to force you to start using new
> optional features... Eventually classic classes will go away, but
> that will be a long time.
--
Michael Gilfix
mgilfix@eecs.tufts.edu
For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4