On 05.10.2016 18:06, Nick Coghlan wrote:
[runtime matters]
I think I understand your point.
I also hope that others and me could provide you with our perspective.
We see Python not as a C-like runtime but as an abstract modelling
language. I know that it's different from the point of view of CPython
internals, however from the outside Python suggests to be much more than
a simple wrapper around C. Just two different perspectives.
Unfortunately, your runtime explanations still don't address the DRY
issue. :-/
Guido's idea of a shadow thread to let synchronous threads run
coroutines without needing to actually run a foreground event loop
should provide a manageable way of getting the two runtime models
(traditional C and asynchronous coroutines) to play nicely together in
a single application, and has the virtue of being something folks can
readily experiment with for themselves before we commit to anything
specific in the standard library (since all the building blocks of
thread local storage, event loop management, and inter-thread message
passing primitives are already available).
I needed to think about this further when Guido mentioned it. But I like
it now.
If you check https://github.com/srkunze/fork/tree/asyncio , I already
started working on integrating asyncio into xfork at long time ago. But
I still couldn't wrap my mind around it and it stalled. But IIRC, I
would have implemented a shadow thread solution as well. So, if his idea
goes into the stdlib first, I welcome it even more as it would do the
heavy lifting for me. xfork would then be just a common interface to
threads, processes and coroutines.
Cheers,
Sven
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
