[Python-ideas] PEP draft: context variables
Nathaniel Smith
njs at pobox.com
Mon Sep 4 20:49:56 EDT 2017
More information about the Python-ideas mailing list
Mon Sep 4 20:49:56 EDT 2017
- Previous message (by thread): [Python-ideas] PEP draft: context variables
- Next message (by thread): [Python-ideas] PEP draft: context variables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Sep 4, 2017 at 2:50 PM, Koos Zevenhoven <k7hoven at gmail.com> wrote: > Hi all, > > as promised, here is a draft PEP for context variable semantics and > implementation. Apologies for the slight delay; I had a not-so-minor > autosave accident and had to retype the majority of this first draft. > > During the past years, there has been growing interest in something like > task-local storage or async-local storage. This PEP proposes an alternative > approach to solving the problems that are typically stated as motivation for > such concepts. >From a quick skim, my impression is: All the high-level semantics you suggest make sense... in fact, AFAICT they're exactly the same semantics we've been using as a litmus test for PEP 550. I think PEP 550 is sufficient to allow implementing all your proposed APIs (and that if it isn't, that's a bug in PEP 550). OTOH, your proposal doesn't provide any way to implement functions like decimal.setcontext or numpy.seterr, except by pushing a new state and never popping it, which leaks memory and permanently increases the N in the O(N) lookups. I didn't see any direct comparison with PEP 550 in your text (maybe I missed it). Why do you think this approach would be better than what's in PEP 550? -n -- Nathaniel J. Smith -- https://vorpus.org
- Previous message (by thread): [Python-ideas] PEP draft: context variables
- Next message (by thread): [Python-ideas] PEP draft: context variables
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-ideas mailing list