[Python-Dev] PEP 384 accepted (original) (raw)

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 buildext and in the compilers. So you will need to try out ALL projects out there that customize buildext, 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.

Matthias

More information about the Python-Dev mailing list