Jack Jansen wrote:
On dinsdag, mei 28, 2002, at 07:00 , Guido van Rossum wrote:
Now consider my frustration. We go through a lot of efforts to make consecutive releases backwards compatible, to document changes, to introduce warnings about future incompatible changes, etc.
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.
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?), 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 see the argument here ? You don't seriously expect all extensions, add-ons, existing applications, etc. to be rewritten, patched or changed in other ways with every new Python release, or do you ?
Python builds a lot of its popularity on the huge number of add-ons you can download from the web.
We should be very careful not to break these in ways which make them unusable, because otherwise, we'll have frustrated users and these would be seriously bad for continuing the ride on the wave we're currently seeing.
The developer side of things is a little different, since there changes cost time which is usually a rare resource. For small companies it also costs money which they usually don't have.
(A migration guide would help both.)
In summary, rapid change is not a good approach to a stable product, rapid bug fixing and addition of useful enhancements in backward compatible ways after longer trial phases is, at least IMHO.
-- Marc-Andre Lemburg CEO eGenix.com Software GmbH