On Mon, Aug 28, 2017 at 12:12:00PM -0400, Yury Selivanov wrote:
On Mon, Aug 28, 2017 at 11:52 AM, Stefan Krah <stefan@bytereef.org> wrote: [..]
But the state "leaks in" as per your previous example:
async def bar(): # use decimal with context=ctx
async def foo(): decimal.setcontext(ctx) await bar()
IMHO it shouldn't with coroutine-local-storage (let's call it CLS). So, as I see it, there's still some mixture between dynamic scoping and CLS because it this example bar() is allowed to search the stack.
The whole proposal will then be mostly useless. If we forget about the dynamic scoping (I don't know why it's being brought up all the time, TBH; nobody uses it, almost no language implements it)
Because a) it was brought up by proponents of the PEP early on python-ideas, b) people desperately want a mental model of what is going on. :-)
* 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". So perhaps Nathaniel is right that the PEP is not so useful for numpy and decimal backwards compat. Stefan Krah