[Python-Dev] 2.3.5 schedule, and something I'd like to get in

[Jack Jansen]

[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