On Tue, 2020-04-21 at 11:21 -0500, Sebastian Berg wrote: > On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote: > > Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith <n...@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 > 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-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/3MK2NANMOJFHKJWELGI2ZD74K2ZYJAOD/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ > 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/ONEVR72KRC6VZR3X47BF5XOD5ZAVDQTZ/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ 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/GX76SGCGO2TWTBCTBQ4CWNEZK6I6BUC4/ Code of Conduct: http://python.org/psf/codeofconduct/
