Yury Selivanov wrote:
On Mon, Aug 28, 2017 at 1:33 PM, Stefan Krah <ste...@bytereef.org> wrote:
[..]
* Context managers like decimal contexts, numpy.errstate, and
warnings.catch_warnings.
The decimal context works like this:
1) There is a default context template (user settable).
2) Whenever the first operation *in a new thread* occurs, the
thread-local context is initialized with a copy of the
template.
I don't find it very intuitive if setcontext() is somewhat local in
coroutines but they don't participate in some form of CLS.
You have to think about things like "what happens in a fresh thread
when a coroutine calls setcontext() before any other decimal operation
has taken place".
I'm sorry, I don't follow you here.
PEP 550 semantics:
setcontext() in a regular code would set the context for the whole thread.
setcontext() in a coroutine/generator/async generator would set the
context for all the code it calls.
So perhaps Nathaniel is right that the PEP is not so useful for numpy
and decimal backwards compat.
Nathaniel's argument is pretty weak as I see it. He argues that some
people would take the following code:
def bar():
# set decimal context
def foo():
bar()
# use the decimal context set in bar()
and blindly convert it to async/await:
async def bar():
# set decimal context
async def foo():
await bar()
# use the decimal context set in bar()
And that it's a problem that it will stop working.
But almost nobody converts the code by simply slapping async/await on
top of it
Maybe not, but it will also affect refactoring of code
that is *already* using async/await, e.g. taking
async def foobar():
# set decimal context
# use the decimal context we just set
and refactoring it as above.
Given that one of the main motivations for yield-from
(and subsequently async/await) was so that you *can*
perform that kind of refactoring easily, that does
indeed seem like a problem to me.
It seems to me that individual generators/coroutines
shouldn't automatically get a context of their own,
they should have to explicitly ask for one.
--
Greg
-- things don't work this way. It was never a goal for
async/await or asyncio, or even trio/curio. Porting code to
async/await almost always requires a thoughtful rewrite.
In async/await, the above code is an *anti-pattern*. It's super
fragile and can break by adding a timeout around "await bar". There's
no workaround here.
Asynchronous code is fundamentally non-local and a more complex topic
on its own, with its own concepts: Asynchronous Tasks, timeouts,
cancellation, etc. Fundamentally: "(synchronous code) !=
(asynchronous code) - (async/await)".
Yury
_______________________________________________
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/greg.ewing%40canterbury.ac.nz
_______________________________________________
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
