RetroSearch Browse

Wed Oct 18 02:25:15 EDT 2017 · https://mail.python.org/pipermail/python-dev/2017-October/149911.html

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~

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2017-October/149911.html below:

[Python-Dev] Timeout for PEP 550