It is a nuisance. It's more of a nuisance when third part modules with 'c' components are compiled for the new version of python (a windows specific problem).
I did find that the last upgrade forced me to evaluate which extensions I actually used. The answer was 'a few less than I thought'. It became a good opportunity to spring clean my 'site-packages' folder.
I find this part of the story a nuisance, C components in 3rd party modules... What are the C components compiled into? What are actually "so" files?
I am using Fink to maintain my Python installation and Fink maintains the 3rd party libraries in /sw/lib/python2.3/site-packages. Imagine the trouble if I do a "fink selfupdate" and "fink update-all" and finds that my Python is replaced by a newer version, say Python 2.4. Then all my 3rd party libraries in /sw/lib/python2.3/site-packages are un-usable... And I will have to re-download and re-install all the libraries again.
Yes, I do agree that it is a nice time to clean out "site-packages" but imagine the work of a system admin who has to re-install 50 packages... I do believe that we can use some help here, if possible... Perhaps someone can enlighten us on the technicalities of "so" files and/or C bindings in Python...
Now I understand that Python bytecodes are only dealing with pure python source codes. However, the same question lies, how can it (set of bytecodes) be made stable, like Java bytecodes, which are pretty stable? Perhaps a better question will be, what techniques Java VM designers use that enables Java class files (and JAR files) to be stable and usable across versions that is lacking in Python?
Thanks.
Cheers Maurice -- http://mail.python.org/mailman/listinfo/python-list
