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

[Jack Jansen]

First question: what is the Python 2.3.5 release schedule and who is 
responsible?

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?

And now the question that matters: there's some stuff I'd really like 
to get into 2.3.5, but it involves changes to configure, the Makefile 
and distutils, so because it's fairly extensive I thought I'd ask 
before just committing it.

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. That's 
fine for most uses of frameworks, but not when linking a Python 
extension against the Python framework: if you build an extension with 
Python 2.3 to later load it into 2.3 you don't want that framework to 
be linked against 2.4.

Now there's a way around this, from MacOSX 10.3 onwards, and that is 
not to link against the framework at all, but link with "-undefined 
dynamic_lookup". This will link the extension in a way similar to what 
other Unix systems do: any undefined externals are looked up when the 
extension is dynamically loaded. But because this feature only works 
with the dynamic loader from 10.3 or later you must have the 
environment variable MACOSX_DEPLOYMENT_TARGET set to 10.3 or higher 
when you build the extension, otherwise the linker will complain.

We've solved this issue for the trunk and we can solve it for 2.4.1: if 
MACOSX_DEPLOYMENT_TARGET isn't set and we're on 10.3 we force it to 
10.3. Moreover, when it is 10.3 or higher (possibly after being forced) 
we use the dynamic_lookup way of linking extensions. We also record the 
value of MACOSX_DEPLOYMENT_TARGET in the Makefile, and distutils picks 
it up later and sets the environment variable again.

We even have a hack to fix Apple-installed Python 2.3 in place by 
mucking with lib/config/Makefile, which we can do because 
Apple-installed Python 2.3 will obviously only be run on 10.3. And we 
check whether this hack is needed when you install a later Python 
version on 10.3.

That leaves Python 2.3.5 itself. The best fix here would be to backport 
the 2.4.1 solution: configure.in 1.456 and 1.478, 
distutils/sysconfig.py 1.59 and 1.62, Makefile.pre.in 1.144. Note that 
though the build procedure for extensions will change it doesn't affect 
binary compatibility: both types of extensions are loadable by both 
types of interpreters.

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.
--
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