bytecode non-backcompatibility

[Maurice LING]

Martin v. Löwis wrote:
> Maurice LING wrote:
> 
>>technicalities are wrong but situation remains unchanged.
> 
> 
> For C modules, it is very likely that new versions of Python
> will continue to break the ABI, by changing the layout of
> structures.
> 
> The most straight-forward way to deal with it as a sysadmin
> or user is to install multiple versions of Python on a single
> machine. If Fink considers python2.4 as a replacement for
> python2.3, then this is a flaw in Fink. In Debian, there is
> a python package, which currently depends on python2.3.
> Sometime in the future, it will depend on python2.4. Users
> which update will then get python2.4, however, python2.3
> will remain installed and usable, with all the extension
> modules that were installed for it.
> 
> Regards,
> Martin

Fink does not consider python2.4 to be a replacement for python2.3. In 
fact, you can install python2.2, 2.3 and 2.4 in the same machine with 
Fink. It will maintain 3 sets of libraries as /sw/lib/python2.2, 
/sw/lib/python2.3 and /sw/lib/python2.4. The chore is that when say Fink 
installs python2.4, all the libraries in /sw/lib/python2.3/site-packages 
have to be re-installed into /sw/lib/python2.4/site-packages, one by 
one. There is no simple way of doing that... which makes any system 
admin needing to re-install 50 3rd party libraries into 
/sw/lib/python2.4/site-packages a big task, as well as satisfying the 
necessary dependencies.

So if C extension API (or whatever that is really called) is stable, the 
system admin can just copy all of /sw/lib/python2.3/site-packages into 
/sw/lib/python2.4/site-packages and it should work. From what you've 
said, it seems that this isn't possible. So my alternative solution is 
that PyPI have a mechanism to maintain what had been installed in the 
site-package directory and to download the libraries and install into 
the new site-package directory...

What do you think?

Cheers
maurice