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/archive%40mail-archive.com
