I think we've debated the design of ContextVar and default values enough. Regardless of the philosophical questions around "what is a variable", I agree that Yury's current design is right, so let's move on to other topics (if there are any).
On Thu, Jan 11, 2018 at 12:55 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 11 January 2018 at 07:39, Chris Jerdonek <chris.jerdo...@gmail.com> > wrote: > > But to your question, like it or not, I think the API encourages this > > way of thinking because the get() method is on the ContextVar itself, > > and so it's the ContextVar which is doing the looking up rather than > > just fulfilling the role of a key name. The API brings to mind other > > containers and things holding values like dict.get(), queue.get(), > > BytesIO.getvalue(), and container type's object.__getitem__(), etc. So > > I think one will need to be prepared for many or most users having > > this conception with the current API. (I think renaming to something > > like ContextVar.lookup() or even ContextVar.value() would go a long > > way towards dispelling that, but Guido said earlier in the thread that > > he likes the shorter name.) > > I can only offer anecdotal evidence, but I am perfectly comfortable > with seeing ContextVars as names (variables) that refer to values, and > not as containers of values. The "Var" part of the class name is what > makes that link in my head, I think, and it is a stronger association > for me than the idea that get() implies a container. > > So I'm 100% fine, personally, with ContextVars as names that refer to > values (that you access via the get() method), and with the Context as > a hidden lookup table for those values (corresponding to > globals()/locals()). I'm also OK on that same basis with ContextVars > having an "unset" state, and with it being unusual/difficult to get > back to the unset state once you've set a value. > > tl;dr If you think of a ContextVar as a "variable" or "name", the > current design makes sense (at least to me). > > Paul > _______________________________________________ > 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/ > guido%40python.org > -- --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
