Showing content from http://mail.python.org/pipermail/python-dev/attachments/20180105/6ec0a5e7/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 5, 2018 at 2:43 PM, Chris Jerdonek <span dir="ltr"><<a href="mailto:chris.jerdonek@gmail.com" target="_blank">chris.jerdonek@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 Fri, Jan 5, 2018 at 8:29 AM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Fri, Jan 5, 2018 at 2:05 AM, Victor Stinner <<a href="mailto:victor.stinner@gmail.com">victor.stinner@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Currently, Context.get(var) returns None when "var in context" is false.<br>
>> That's surprising and different than var.get(), especially when var has a<br>
>> default value.<br>
><br>
> I don't see the problem. Context.get() is inherited from Mapping.get(); if<br>
> you want it to raise use Context.__getitem__() (i.e. ctx[var]). Lots of<br>
> classes define get() methods with various behaviors. Context.get() and<br>
> ContextVar.get() are just different -- ContextVar is not a Mapping.<br>
<br>
</span>One thing that I think could be contributing to confusion around the<br>
proposed API is that there is a circular relationship between Context<br>
and ContextVar, e.g. ContextVar.get() does a lookup in the current<br>
Context with "self" (the ContextVar object) as a key....<br>
<br>
Also, it's the "keys" (the ContextVar objects) that have the get()<br>
method that should be used rather than the container object (the<br>
Context). This gives the confusing *feeling* of a mapping of mappings.<br>
This is different from how the containers people are most familiar<br>
with work -- like dict.<br></blockquote><div><br></div><div>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.)<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Is there a reason ContextVar needs to be exposed publicly at all? For<br>
example, the API could use string keys like contextvars.get(name) or<br>
Context.get(name) (class method). There could be separate functions to<br>
initialize keys with desired default values, etc (internally creating<br>
ContextVars as needed).<br>
<br>
If the issue is key collisions, it seems like this could be handled by<br>
namespacing or using objects (namespaced by modules) instead of<br>
strings.<br>
<br>
Maybe this approach was ruled out early on in discussions, but I don't<br>
see it mentioned in the PEP.<br></blockquote><div><br></div><div>Yes this was litigated repeatedly. Maybe the PEP 550 discussion or Rejected Ideas section have more.<br></div><div>Â </div></div>-- <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></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4