[Python-Dev] PEP 567 pre v3 (original) (raw)

Guido van Rossum guido at python.org
Fri Jan 12 14:38:55 EST 2018


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.moore at gmail.com> wrote:

On 11 January 2018 at 07:39, Chris Jerdonek <chris.jerdonek at 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 at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20180112/4148438b/attachment.html>



More information about the Python-Dev mailing list