[Python-Dev] On track for Python 2.6.4 final this Sunday? (original) (raw)

P.J. Eby pje at telecommunity.com
Tue Oct 13 18:23:34 CEST 2009

At 05:42 PM 10/13/2009 +0200, M.-A. Lemburg wrote:

FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be able to get rid off the few remaining hacks !

Thanks for the nice (and neutral) explanation, for those not up to speed on the details.

Of course, had the change been made in 2.7 rather than 2.6.3, there wouldn't have been a problem here. People understand that new major versions sometimes mean that existing packages will need to adapt and cope. Under normal circumstances, however, a dot release shouldn't break packages that worked with previous dot releases. (At least, that's the common expectation.)

Now, I do have to admit that I'm still ignorant of what bug this was trying to fix in the first place. You say it "was needed to get inplace installations working", but I don't know what that means, since AFAIK inplace extension builds (build_ext -i) have been working since before the first versions of setuptools appeared in 2003.

So, if there was a bug in build_ext that wasn't introduced in 2.6, it seems like 2.6.3 would be an odd place to fix that bug.

This isn't intended as a criticism of anybody, mind you; I'm just saying that I still don't understand why the change was made in 2.6.3 in the first place, and it would be kind of nice to know. These kinds of situations can be useful for illustrating and improving Python policy, if the root causes and reasoning are understood by everyone.

More information about the Python-Dev mailing list