On 10/17/2017 09:40 PM, Nick Coghlan wrote:
On 18 October 2017 at 05:55, Yury Selivanov wrote:
I actually like what you did in
https://github.com/gvanrossum/pep550/blob/master/simpler.py
<https://github.com/gvanrossum/pep550/blob/master/simpler.py>, it seems
reasonable. The only thing that I'd change is to remove "set_ctx"
from the public API and add "Context.run(callable)". This makes the
API more flexible to potential future changes and amendments.
Yep, with that tweak, I like Guido's suggested API as well.
Attempting to explain why I think we want "Context.run(callable)" rather
"context_vars.set_ctx()" by drawing an analogy
to thread local storage:
1. In C, the compiler & CPU work together to ensure you can't access another
thread's thread locals.
2. In Python's thread locals API, we do the same thing: you can only get access
to the running thread's thread locals,
not anyone else's
At the Python API layer, we don't expose the ability to switch explicitly to
another thread state while remaining within
the current function. Instead, we only offer two options: starting a new
thread, and waiting for a thread to finish
execution. The lifecycle of the thread local storage is then intrinsically
linked to the lifecycle of the thread it
belongs to.
I seem to remember mention about frameworks being able to modify contexts for various tasks/coroutines; if the framework
cannot create and switch to a new context how will it set them up? Or did I misunderstand?
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
