On Fri, Jan 5, 2018 at 2:43 PM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote:
> 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. > Only if you think of ContextVar as a mapping, which is not at all how it works. (If anything, its get() method is more like that on weak references.) > 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. > Yes this was litigated repeatedly. Maybe the PEP 550 discussion or Rejected Ideas section have more. -- --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/archive%40mail-archive.com