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.
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 firstname.lastname@example.org
For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html