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. Matthias
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4