Yury Selivanov added the comment:
> I started a local PR at https://github.com/ncoghlan/cpython/pull/1/files to
> explore what this might look like in practice.
Looks good to me.
> I'm less sure about __delegated_to__/__returns_to__, since we don't have
> *any* code in the standard library t
Nick Coghlan added the comment:
I started a local PR at https://github.com/ncoghlan/cpython/pull/1/files to
explore what this might look like in practice.
I think that what I've done so far shows that generic __frame__ and __running__
attributes would be sufficient to extend the inspect module
Nick Coghlan added the comment:
I agree https://bugs.python.org/issue31197 is orthogonal - refactoring the
current logic is useful regardless of what we do at the object attribute layer.
Regarding __delegated_to__/__returns_to__, the reason I like *not* having
"async" in the attribute names is
syncosmic added the comment:
I like where this is heading! Aside from the cleaner patterns for handling
these objects, I think it'll make it a little easier for people who are just
starting to use asynchronous objects in Python (e.g. me) to grasp what's
similar about them.
+1 that `__async_ca
Nick Coghlan added the comment:
Slight amendment: `__delegated_to__` and `__returns_to__` might be better names
for the doubly-linked list of the async call chain.
"__async_call__" and "__async_return__" both have the problem that they look
like imperative commands (since "call" and "return" a
