[Python-Dev] 2.3.5 schedule, and something I'd like to get in (original) (raw)
Jack Jansen Jack.Jansen at cwi.nl
Thu Jan 6 00:21:58 CET 2005
- Previous message: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
- Next message: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Grmpf. I should check which account I use before pressing send. Here
goes again]
On 5-jan-05, at 1:08, Bob Ippolito wrote:
The problem we're trying to solve is that due to the way Apple's framework architecture works newer versions of frameworks are preferred (at link time, and sometimes even at runtime) over older ones.
Can you elaborate on that somewhat? According to http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFrameworks/Concepts/VersionInformation.html there are major and minor versions of frameworks. I would think that every Python minor (2.x) release should produce a new major framework version of the Python framework. Then, there would be no problem. Why does this not work? It doesn't for reasons I care not to explain in depth, again.
But I do care:-) Specifically because I trust the crowd here to come up
with good ideas (even if they're not Mac users:-).
Ronald already explained most of the problem, what it boils down to is
that multiple versions of a framework can live in a single location.
For most applications that's better than the old MacOS9 architecture
(which I believe is pretty similar to the Windows dll architecture)
because you can ship a single foo.framework that contains both version
1.2 and 1.3. There's also a symlink "Current" that will point to 1.3.
At build time the linker will pick the version pointed at by "Current",
but in the file it will record the actual version number. Hence, if you
ship this framework new development will link to the newest version,
but older programs will still load the older one.
When I did the framework python design I overlooked the fact that an
older Python would have no way to specify that an extension would have
to link against its own, old, framework, because on MacOS9 this wasn't
a problem (the two had different filenames).
As an aside, I also overlooked the fact that a Python framework
residing in /System could be overridden by one in /Library because in
2.3 we linked frameworks by relative pathname, because I simply didn't
envision any Python living in /System for some time to be. The -F
options could solve that problem, but not the 2.3 and 2.4 both in
/Library problem.
The "new" solution is basically to go back to the Unix way of building
an extension: link it against nothing and sort things out at runtime.
Not my personal preference, but at least we know that loading an
extension into one Python won't bring in a fresh copy of a different
interpreter or anything horrible like that.
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
Goldman
- Previous message: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
- Next message: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]