On 21 Apr 2020, at 03:21, Eric Snow <ericsnowcurrently@gmail.com> wrote:
[…]
On Mon, Apr 20, 2020 at 4:30 PM Nathaniel Smith <njs@pobox.com> wrote:
[…]
But notice that this means that no-one can use subinterpreters at all, until all of their C extensions have had significant reworks to use the new API, which will take years and tons of work -- it's similar to the Python 3 transition. Many libraries will never make the jump.
Again, that is a grand statement that makes things sound much worse than they really are. I expect very very few extensions will need "significant reworks". Adding PEP 489 support will not take much effort, on the order of minutes. Dealing with process-global state will depend on how much, if any.
Honest question: how many C extensions have process-global state that will cause problems under subinterpreters? In other words, how many already break in mod_wsgi?
Fully supporting sub-interpreters in PyObjC will likely be a lot of work, mostly due to being able to subclass Objective-C classes from Python. With sub-interpreters a Python script in an interpreter could see an Objective-C class in a different sub-interpreter. The current PyObjC architecture assumes that there’s exactly one (sub-)interpreter, that’s probably fixable but is far from trivial. With the current API it might not even be possible to add sub-interpreter support (although I write this without having read the PEP). As far as I understand proper support for subinterpreters also requires moving away from static type definitions to avoid sharing objects between interpreters (that is, use the PyType_FromSpec to build types). At first glance this API does not support everything I do in PyObjC (fun with metaclasses, in C code). BTW. I don’t have a an opinion on the PEP itself at this time, mostly because it doesn’t match my current use cases. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/