<div dir="ltr">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).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 12:55 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 11 January 2018 at 07:39, Chris Jerdonek <<a href="mailto:chris.jerdonek@gmail.com">chris.jerdonek@gmail.com</a>> wrote:<br>
> But to your question, like it or not, I think the API encourages this<br>
> way of thinking because the get() method is on the ContextVar itself,<br>
> and so it's the ContextVar which is doing the looking up rather than<br>
> just fulfilling the role of a key name. The API brings to mind other<br>
> containers and things holding values like dict.get(), queue.get(),<br>
> BytesIO.getvalue(), and container type's object.__getitem__(), etc. So<br>
> I think one will need to be prepared for many or most users having<br>
> this conception with the current API. (I think renaming to something<br>
> like ContextVar.lookup() or even ContextVar.value() would go a long<br>
> way towards dispelling that, but Guido said earlier in the thread that<br>
> he likes the shorter name.)<br>
<br>
</span>I can only offer anecdotal evidence, but I am perfectly comfortable<br>
with seeing ContextVars as names (variables) that refer to values, and<br>
not as containers of values. The "Var" part of the class name is what<br>
makes that link in my head, I think, and it is a stronger association<br>
for me than the idea that get() implies a container.<br>
<br>
So I'm 100% fine, personally, with ContextVars as names that refer to<br>
values (that you access via the get() method), and with the Context as<br>
a hidden lookup table for those values (corresponding to<br>
globals()/locals()). I'm also OK on that same basis with ContextVars<br>
having an "unset" state, and with it being unusual/difficult to get<br>
back to the unset state once you've set a value.<br>
<br>
tl;dr If you think of a ContextVar as a "variable" or "name", the<br>
current design makes sense (at least to me).<br>
<span class="HOEnZb"><font color="#888888"><br>
Paul<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>