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

[Bob Ippolito]

On Jan 4, 2005, at 6:54 PM, Martin v. Löwis wrote:

> Jack Jansen wrote:
>> First question: what is the Python 2.3.5 release schedule and who is  
>> responsible?
>
> Last I heard it is going to be released "in January", and Anthony  
> Baxter
> is the release manager.
>
>> Second question: I thought this info was in a PEP somewhere, but I  
>> could only find PEPs on major releases, should I have found this info  
>> somewhere?
>
> By following python-dev, or in a python-dev summary, e.g.
>
> http://www.python.org/dev/summary/2004-11-01_2004-11-15.html
>
>> 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.  Search  
the pythonmac-sig archives for longer explanations.  The gist is that  
you specifically do not want to link directly to the framework at all  
when building extensions.  These patches are required to do that  
correctly.

>> I think this is all safe, and these patches shouldn't affect any  
>> system other than MacOSX, but I'm a bit reluctant to fiddle with the  
>> build procedure for a micro-release, so that's why I'm asking.
>
> This is ultimately for the release manager to decide. My personal
> feeling is that it is ok to fiddle with the build procedure. I'm
> more concerned that the approach taken might be "wrong", in the
> sense that it uses a stack of hacks and work-arounds for problems
> which Apple envisions to be solved differently. That would be bad,
> because it might make an implementation of the "proper" solution
> more difficult.

This is not the wrong way to do it.

-bob