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

Jack Jansen Jack.Jansen at cwi.nl
Wed Jan 5 00:06:29 CET 2005

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

More information about the Python-Dev mailing list