> On 21 Apr 2020, at 03:21, Eric Snow <ericsnowcurren...@gmail.com> wrote: > […] > On Mon, Apr 20, 2020 at 4:30 PM Nathaniel Smith <n...@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/ _______________________________________________ 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/IK3SSUVHZ3B6G77X6PNYDXMA42TFD23B/ Code of Conduct: http://python.org/psf/codeofconduct/
