[Python-Dev] PEP 550 v4
yselivanov.ml at gmail.com
Mon Aug 28 11:23:12 EDT 2017
On Mon, Aug 28, 2017 at 7:19 AM, Stefan Krah <stefan at bytereef.org> wrote:
> On Sun, Aug 27, 2017 at 11:19:20AM -0400, Yury Selivanov wrote:
>> On Sun, Aug 27, 2017 at 6:08 AM, Stefan Krah <stefan at bytereef.org> wrote:
>> > On Sat, Aug 26, 2017 at 04:13:24PM -0700, Nathaniel Smith wrote:
>> >> It's perfectly reasonable to have a script where you call
>> >> decimal.setcontext or np.seterr somewhere at the top to set the
>> >> defaults for the rest of the script.
>> > +100. The only thing that makes sense for decimal is to change localcontext()
>> > to be automatically async-safe while preserving the rest of the semantics.
>> TBH Nathaniel's argument isn't entirely correct.
>> With the semantics defined in PEP 550 v4, you still can set decimal
>> context on top of your file, in your async functions etc.
>> and this:
>> def bar():
>> def foo():
>> # use decimal with context=ctx
> Okay, so if I understand this correctly we actually will not have dynamic
> scoping for regular functions: bar() has returned, so the new context
> would not be found on the stack with proper dynamic scoping.
Correct. Although I would avoid associating PEP 550 with dynamic
scoping entirely, as we never intended to implement it.
> What about this?
> async def bar():
> for i in range(10):
> await asyncio.sleep(1)
> yield i
> async def foo():
> async for i in bar():
> # ctx.prec=1?
> print(Decimal(100) / 3)
> I'm searching for some abstract model to reason about the scopes.
Whatever is set in coroutines, generators, and async generators does
not leak out. In the above example, "prec=1" will only be set inside
"bar()", and "foo()" will not see that. (Same will happen for a
regular function and a generator).
More information about the Python-Dev