[Python-Dev] On track for Python 2.6.4 final this Sunday?

[P.J. Eby]

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.