bytecode non-backcompatibility

[Maurice LING]

> 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