On Fri, Jan 5, 2018 at 8:29 AM, Guido van Rossum <gu...@python.org> wrote: > On Fri, Jan 5, 2018 at 2:05 AM, Victor Stinner <victor.stin...@gmail.com> > wrote: >> >> Currently, Context.get(var) returns None when "var in context" is false. >> That's surprising and different than var.get(), especially when var has a >> default value. > > I don't see the problem. Context.get() is inherited from Mapping.get(); if > you want it to raise use Context.__getitem__() (i.e. ctx[var]). Lots of > classes define get() methods with various behaviors. Context.get() and > ContextVar.get() are just different -- ContextVar is not a Mapping.
One thing that I think could be contributing to confusion around the proposed API is that there is a circular relationship between Context and ContextVar, e.g. ContextVar.get() does a lookup in the current Context with "self" (the ContextVar object) as a key.... Also, it's the "keys" (the ContextVar objects) that have the get() method that should be used rather than the container object (the Context). This gives the confusing *feeling* of a mapping of mappings. This is different from how the containers people are most familiar with work -- like dict. Is there a reason ContextVar needs to be exposed publicly at all? For example, the API could use string keys like contextvars.get(name) or Context.get(name) (class method). There could be separate functions to initialize keys with desired default values, etc (internally creating ContextVars as needed). If the issue is key collisions, it seems like this could be handled by namespacing or using objects (namespaced by modules) instead of strings. Maybe this approach was ruled out early on in discussions, but I don't see it mentioned in the PEP. --Chris > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > 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/chris.jerdonek%40gmail.com > _______________________________________________ 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