[Python-Dev] PEP 550 V5 (original) (raw)

Guido van Rossum guido at python.org
Sat Sep 2 01:08:50 EDT 2017

On Fri, Sep 1, 2017 at 8:29 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:

Nice working staying on top of this! Keeping up with discussion is arguably much harder than actually writing the PEP. :) I have some comments in-line below.

-eric

On Fri, Sep 1, 2017 at 5:02 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote: > [snip] > > Abstract > ======== > > [snip] > > Rationale > ========= > > [snip] > > Goals > ===== > I still think that the Abstract, Rationale, and Goals sections should be clear that a major component of this proposal is lookup via chained contexts. Without such clarity it may not be apparent that chained lookup is not strictly necessary to achieve the stated goals (i.e. an async-compatible TLS replacement). This matters because the chaining introduces extra non-trivial complexity.

In defense of the PEP, the Goals section clearly states it aims to provide an alternative, not a plug-in API equivalent.

There's also been some discussion (I hope it wasn't off-list) on how to implement threading.local on top of this proposal.

That said, I agree it would be nice if the chained lookup was mentioned in the abstract too, because it's a pretty essential part of the proposal (it determines the semantics of ContextVar). (OTOH the HAMT implementation is less essential, there's another way to do the chained lookup.)

> [snip]

On the one hand the first three sections imply that the PEP is intended as a replacement for the current TLS mechanism; threading.local. On the other hand, the PEP (and related discussion) clearly says that the feature works differently than threading.local and hence is not a (drop-in) replacement. I'd prefer it to be a drop-in replacement but recognize I'm on the losing side of that argument. :P Regardless, having a consistent message in the PEP would help folks looking to switch over. Speaking of which, I have plans for the near-to-middle future that involve making use of the PEP 550 functionality in a way that is quite similar to decimal. However, it sounds like the implementation of such (namespace) contexts under PEP 550 is much more complex than it is with threading.local (where subclassing made it easy). It would be helpful to have some direction in the PEP on how to port to PEP 550 from threading.local. It would be even better if the PEP included the addition of a contextlib.Context or contextvars.Context class (or NamespaceContext or ContextNamespace or ...). :) However, I recognize that may be out of scope for this PEP.

If you look at what decimal does, it only ever stores a single value in its threading.local instance -- decimal_context. (And part of the reason is that the C version has to work with a different API for TLS, which really does only store a single value per key.)

-- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20170901/e0247917/attachment.html>

More information about the Python-Dev mailing list