On Wed, Feb 9, 2011 at 11:03 PM, <exarkun at twistedmatrix.com> wrote: > On 12:43 pm, ncoghlan at gmail.com wrote: >> >> On Wed, Feb 9, 2011 at 10:11 PM, Mark Shannon <marks at dcs.gla.ac.uk> wrote: >>> >>> OK, so UnicodeError_xxx is important for codecs, but surely this sort of >>> argument could be made for lots of things. >>> Don't forget that for each function added to the API, >>> all other implementations have to support it forever. >> >> Other implementations that want to support CPython extensions should >> focus their efforts on the limited API defined in PEP 384. That will >> not only be a lot easier, it will also be less of a moving target. > > And will produce what kind of results? How many extension libraries work > with this subset? Right now? Very few, given the changes to the way types need to be created. But prioritising it will speed convergence over time as more extension modules cut over to it for the stable ABI benefits. And, since the C API has never been anywhere near as tightly controlled as the language definition, alternative implementations are going to garner more sympathy if they restrict their concerns to the growth of the stable ABI rather than worrying about an implementation detail of CPython. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
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