Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171016/39fd1b6e/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.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 Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> Yes, that's what I meant by "ignoring generators". And I'd like there to be<br>
> a "current context" that's a per-thread MutableMapping with ContextVar keys.<br>
> Maybe there's not much more to it apart from naming the APIs for getting and<br>
> setting it? To be clear, I am fine with this being a specific subtype of<br>
> MutableMapping. But I don't see much benefit in making it more abstract than<br>
> that.<br>
<br>
</span>We don't need it to be abstract (it's fine to have a single concrete<br>
mapping type that we always use internally), but I think we do want it<br>
to be opaque (instead of exposing the MutableMapping interface, the<br>
only way to get/set specific values should be through the ContextVar<br>
interface). The advantages are:<br>
<br>
- This allows C level caching of values in ContextVar objects (in<br>
particular, funneling mutations through a limited API makes cache<br>
invalidation *much* easier)<br></blockquote><div><br></div><div>Well the MutableMapping could still be a proxy or something that invalidates the cache when mutated. That's why I said it should be a single concrete mapping type. (It also doesn't have to derive from MutableMapping -- it's sufficient for it to be a duck type for one, or perhaps some Python-level code could `register()` it.<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- It gives us flexibility to change the underlying data structure<br>
without breaking API, or for different implementations to make<br>
different choices -- in particular, it's not clear whether a dict or<br>
HAMT is better, and it's not clear whether a regular dict or<br>
WeakKeyDict is better.<br></blockquote><div><br></div><div>I would keep it simple and supid, but WeakKeyDict is a subtype of MutableMapping, and I'm sure we can find a way to implement the full MutableMapping interface on top of HAMT as well.<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The first point (caching) I think is the really compelling one: in<br>
practice decimal and numpy are already using tricky caching code to<br>
reduce the overhead of accessing the ThreadState dict, and this gets<br>
even trickier with context-local state which has more cache<br>
invalidation points, so if we don't do this in the interpreter then it<br>
could actually become a blocker for adoption. OTOH it's easy for the<br>
interpreter itself to do this caching, and it makes everyone faster.<br></blockquote><div><br></div><div>I agree, but I don't see how making the type a subtype (or duck type) of MutableMapping prevents any of those strategies. (Maybe you were equating MutableMapping with "subtype of dict"?) <br></div></div><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></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