[Python-Dev] Timeout for PEP 550 / Execution Context discussion

Guido van Rossum guido at python.org
Tue Oct 17 16:16:19 EDT 2017


On Tue, Oct 17, 2017 at 12:51 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Oct 17, 2017 11:25 AM, "Guido van Rossum" <guido at python.org> wrote:
>
>
> In short, I really don't think there's a need for context variables to be
> faster than instance variables.
>
>
> There really is: currently the cost of looking up a thread local through
> the C API is a dict lookup, which is faster than instance variable lookup,
> and decimal and numpy have both found that that's already too expensive.
>

(At first I found this hard to believe, but then I realized that decimal
and numpy presumably access these from C code where a typical operation
like Decimal.__add__ is much faster than a dict lookup. So point taken.)


> Or maybe you're just talking about the speed when the cache misses, in
> which case never mind :-).
>

I'm happy to support caching the snot out of this, but it seems we agree
that the "semantics" can be specified without taking the caching into
account, and that's what I'm after. I presume that each ContextVar object
will have one cached value? Because that's what PEP 550 currently
specifies. Surely it wouldn't be hard for a direct __setitem__ (or
__delitem__) call to cause the cache to be invalidated, regardless of
whether the affected context is a *current* context or not (a bunch of
different approaches suggest themselves).Oother mutating methods can be
implemented in terms of __setitem__ (or __delitem__), and I don't care for
them to be as fast as a cached lookup.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171017/56bc22e1/attachment-0001.html>


More information about the Python-Dev mailing list