On Tue, 2020-04-21 at 11:21 -0500, Sebastian Berg wrote:
Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith <njs@pobox.com> a écrit : <snip> <snip> As far as I can tell, nobody can or _should_ expect subinterpreters to actually run most general python code for many years. Yes, its a chicken-and-egg problem, unless users start to use subinterpreters successfully, C-extensions should probably not even worry to
On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote: transition. This PEP wants to break the chicken-and-egg problem to have a start, but as of now, as far as I can tell, it *must not* promise that it will ever work out.
So, I cannot judge the sentiment or subinterpreters. But it may be good to make it *painfully* clear what you expect from a project like NumPy
Maybe one of the frustrating points about this criticism is that it does not belong in this PEP. And that is actually true! I wholeheartedly agree that it doesn't really belong in this PEP itself. *But* the existence of a document detailing the "state and vision for subinterpreters" that includes these points is probably a prerequisite for this PEP. And this document must be linked prominently from the PEP. So the suggestion should maybe not be to discuss it in the PEP, but to to write it either in the documentation on subinterpreters or as an informational PEP. Maybe such document already exists, but then it is not linked prominently enough probably. - Sebastian
in the next few years. Alternatively, make it painfully clear that you possibly even discourage us from spending time on it now, if its not straight forward. Those using this module are on their own for many years, probably even after success is proven.
Best,
Sebastian
[1] As of now, the way I see it is that I could not even make NumPy (and probably many C extensions) work, because I doubt that the limited API has been exercised enough [2] and I am pretty sure it has holes. Also the PEP about passing module state around to store globals efficiently seems necessary, and is not in yet? (Again, trust: I have to trust you that e.g. what you do to make argument parsing not have overhead in argument clinic will be something that I can use for similar purposes within NumPy)
[2] I hope that we will do (many) these changes for other reasons within a year or so, but they go deep into code barely touched in a decade. Realistically, even after the straight forward changes (such as using the new PEPs for module initialization), these may take up an additional few months of dev time (sure, get someone very good or does nothing else, they can do it much quicker maybe). So yes, from the perspective of a complex C-extension, this is probably very comparable to the 2to3 change (it happened largely before my time though).
[3] E.g. I think I want an ExtensionMetaClass, a bit similar as an ABC, but I would prefer to store the data in a true C-slot fashion. The limited API cannot do MetaClasses correctly as far as I could tell and IIRC is likely even a bit buggy. Are ExtensionMetaClasses crazy? Maybe, but PySide does it too (and as far as I can tell, they basically get away with it by a bit of hacking and relying on Python implementation details.
When asyncio landed in Python 3.4, a few people started to experiment it. Some had a bad experience. Some others were excited and put a few applications in production.
Even today, asyncio didn't replace threads, multiprocessing, concurrent.futures, etc. There are even competitor projects like Twisted, trio and curio! (Also eventlet and gevent based on greenlet which is a different approach). I only started to see very recently project like httpx which supports both blocking and asynchronous API.
I see a slow adoption of asyncio because asyncio solves very specific use cases. And that's fine!
I don't expect that everyone will suddenly spend months of work to rewrite their C code and Python code to be more efficient or fix issues with subinterpreters, until a critical mass of users proved that subinterpreters are amazing and way more efficient!
Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/3MK2NANM... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/ONEVR72K... Code of Conduct: http://python.org/psf/codeofconduct/