[Python-Dev] PEP 384 accepted

Matthias Klose doko at ubuntu.com
Fri Dec 3 02:48:25 CET 2010

On 03.12.2010 00:25, Tarek Ziadé wrote:
> 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.

is this necessary?  are all these projects known to work with 3.2, without 
having changes compared to 3.1 *without* this pep?  hardly ...

how many extensions will use this restricted api at all?  Is it a legitimate 
solution to back up building an extension in the "default" mode?

even without having any changes in distutils it would make sense to know if an 
extension can be built with the restricted ABI, so maybe it is better to defer 
any changes to the extension soname, and provide a check for an extension if it 
conforms to the restricted ABI, even if the extension still uses the python 
version specific soname.

I did not mean to block this pep by choosing any installation names.


More information about the Python-Dev mailing list