> * Hide implementation details from the C API to be able to `optimize > CPython`_ and make PyPy more efficient. > * The expectation is that `most C extensions don't rely directly on > CPython internals`_ and so will remain compatible. > * Continue to support old unmodified C extensions by continuing to > provide the fully compatible "regular" CPython runtime. > * Provide a `new optimized CPython runtime`_ using the same CPython code > base: faster but can only import C extensions which don't use > implementation details. Since both CPython runtimes share the same > code base, features implemented in CPython will be available in both > runtimes. > > Adding my 2cents from someone who does use the CPython API (for a debugger).
I must say I'm -1 until alternative APIs needed are available in the optimized CPython runtime (I'd also say that this is a really big incompatible change and would need a Python 4.0 to do)... I guess that in order for this to work, the first step wouldn't be breaking everyone but talking to extension authors (maybe checking for the users of the APIs which will be deprecated) and seeing alternatives before pushing something which will break CPython extensions which rely on such APIs. I also don't think that CPython should have 2 runtimes... if the idea is to leverage extensions to other CPython implementations, I think going just for a more limited API is the way to go (but instead of just breaking extensions that use the CPython internal API, try to come up with alternative APIs for the users of the current CPython API -- for my use case, I know the debugger could definitely do with just a few simple additions: it uses the internal API mostly because there aren't real alternatives for a couple of use cases). i.e.: if numpy/pandas/<fav library> doesn't adopt the optimized runtime because they don't have the needed support they need, it won't be useful to have it in the first place (you'd just be in the same place where other Python implementations already are). Also, this should probably follow the usual deprecation cycle: do a major CPython release which warns about using the APIs that'll be deprecated and only in the next CPython release should those APIs be actually removed (and when that's done it probably deserves to be called Python 4). Cheers, Fabio
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IT6TQLDRII66K4T42NU2ZFTYOE6GYBRI/ Code of Conduct: http://python.org/psf/codeofconduct/
