> > If we could be sure that a newer Python core shared library could work > > together with an older Python Lib directory (as long as the API > > versions matched) and would provide at least the functionality of that > > older Python version we would be fine: use the API version number in > > the pathname and use the real version number in the lib/python2.2 and > > such. > > While this could work, but it would be confusing: sys.version would be > the version of the core shared library, and applications would expect > to find the corresponding Lib modules. IOW, I don't think it's a > useful feature to have. Ah, bah! Count on Guido to come with a showstopper for a nifty idea:-( This means that we must consider the core shared lib and the lib/python2.2 directory to be very closely coupled. Which in turn means that the only reasonable thing to use as the version number in the framework pathname is the "2.2" style version number. Which means that although all the infrastructure is there we can't have backward compatible plugin modules. Which means Martin was right with his original comment. ... unless there is a way in which we could record a different pathname for the shared library depending on whether we are linking an extension or an application: the former would check that the API version matches, the latter that the 2.2-style version matches. Hmm, MacOSX also has special magic for plugins, I guess it's time to start looking into that. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4