[Python-Dev] PEP 384 accepted

[Tarek Ziadé]

2010/12/2 "Martin v. Löwis" <martin at v.loewis.de>:
>>> No, only the ones that didn't cause backwards incompatibilities,
>>> and broke existing packages.
>>
>> This is impossible. I can point you to some third party project that
>> can break if you touch some distutils internals, like setuptools.
>> Setuptools also uses some privates global variables in some other
>> modules in the stdlib FYI.
>
> So what would break if Extension accepted an abi= keyword parameter?

I suppose you have code behind this, that will be in build_ext and in
the compilers. So you will need to try out ALL projects out there that
customize build_ext, like numpy or setuptools, etc, But you won't be
able to try out all projects because they are not listed somewhere.

For starters, the Extension class is replaced by another one in
setuptools, that patches the constructor if Pyrex is installed,
which is unlikely I guess, so no big deal. But you will also get a
replaced version of the Distribution class that uses a private method
from distutils, and another version of build_ext with custom compiling
flags.

Now depending on how you do your thing it could work if you are
careful at doing things on the top of setuptools.

And then, if numpy.distutils is installed, it relies on distutils
build_ext and tries to rely on setuptools one's too, so it gets in the
mix of the patched classes, and you get an horrible mix and possible
bad interactions.

So I am not saying it's impossible to add the feature, but it is
impossible to be sure nothing gets broken in third party.

So the freeze seems wise indeed

>>> Lift the freeze. I'm all for replacing distutils with distutils2, but
>>> I'm not sure whether you will declare distutils2 ready tomorrow, next
>>> year, or ten years from now.
>>
>> Depends on what "ready" means.
>
> Included in Python, so that changes become possible again.
>
>> If by ready you mean it can be used to replace Distutils1 in a
>> project, I declare Distutils2 ready for usage NOW.  It's in alpha
>> stage. I want a solid beta before Pycon.
>>
>> I would even remove Distutils from 3.x altogether at some point since
>> setuptools is not Python 3 compatible, and just put distutils2.
>>
>> 3.3 sounds like a good target.
>
> So will distuils2 be released before that? If so, when?

An alpha is already released. A beta will be released for Pycon (I
need it for my talk :) )   Then hopefully the final before 3.2


> Regards,
> Martin
>



-- 
Tarek Ziadé | http://ziade.org