[Python-Dev] Timeout for PEP 550 (original) (raw)
[Python-Dev] Timeout for PEP 550 / Execution Context discussion
Nathaniel Smith njs at pobox.com
Mon Oct 16 20:57:06 EDT 2017
- Previous message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Next message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum <guido at python.org> wrote:
On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith <njs at pobox.com> wrote:
On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum <guido at python.org> wrote: > Yes, that's what I meant by "ignoring generators". And I'd like there to > be > a "current context" that's a per-thread MutableMapping with ContextVar > keys. > Maybe there's not much more to it apart from naming the APIs for getting > and > setting it? To be clear, I am fine with this being a specific subtype of > MutableMapping. But I don't see much benefit in making it more abstract > than > that. We don't need it to be abstract (it's fine to have a single concrete mapping type that we always use internally), but I think we do want it to be opaque (instead of exposing the MutableMapping interface, the only way to get/set specific values should be through the ContextVar interface). The advantages are: - This allows C level caching of values in ContextVar objects (in particular, funneling mutations through a limited API makes cache invalidation much easier) 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.
MutableMapping is just a really complicated interface -- you have to deal with iterator invalidation and popitem and implementing view classes and all that. It seems like a lot of code for a feature that no-one seems to worry about missing right now. (In fact, I suspect the extra code required to implement the full MutableMapping interface on top of a basic HAMT type is larger than the extra code to implement the current PEP 550 draft's chaining semantics on top of this proposal for a minimal PEP 550.)
What do you think of something like:
class Context: def init(self, /, init: MutableMapping[ContextVar,object] = {}): ...
def as_dict(self) -> Dict[ContextVar, object]:
"Returns a snapshot of the internal state."
def copy(self) -> Context:
"Equivalent to (but maybe faster than) Context(self.as_dict())."
I like the idea of making it possible to set up arbitrary Contexts and introspect them, because sometimes you do need to debug weird issues or do some wacky stuff deep in the guts of a coroutine scheduler, but this would give us that without implementing MutableMapping's 17 methods and 7 helper classes.
-n
-- Nathaniel J. Smith -- https://vorpus.org
- Previous message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Next message (by thread): [Python-Dev] Timeout for PEP 550 / Execution Context discussion
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]