On Fri, Sep 1, 2017 at 8:29 PM, Eric Snow <ericsnowcurren...@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...@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>)
_______________________________________________ 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
