[Python-Dev] On track for Python 2.6.4 final this Sunday?
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