Nick Coghlan added the comment:

I think there's a strong case for a generic __frame__ attribute, since there 
are plenty of useful things you can do given "object with a linked frame" as a 
protocol (like extract the current locals namespace). We may even want to 
include traceback objects in that particular attribute access consolidation 
(since they have a tb_frame attribute).

Looking at the way inspect.getgeneratorstate() and inspect.getcoroutinestate() 
are implemented, I also think there may be a case for consolidating 
`[gi|cr|ag]_running` into a single `__running__` attribute, such that for 
objects that provide a `__frame__` attribute:

* `__running__` doesn't exist -> not an asynchronous operation
* `__running__ = True` -> running asynchronous operation
* `__running__ = False` -> paused or halted asynchronous operation

Then, rather than adding an inspect API specifically for async generators, we 
could add a general "inspect.getasyncstate()" one that covered all the object 
types, with the possible states:

    ASYNC_RUNNING: __running__ == True, assert __frame__ is not None
    ASYNC_CREATED: __running__ == False, __frame__.f_lasti == -1
    ASYNC_CLOSED: __running__ == False, __frame__ is None
    ASYNC_SUSPENDED: __running__ == False, neither closed nor created

Properly interpreting `gi_yieldfrom` and `[cr|ag]_await` is a bit trickier, 
since they require additional knowledge of how the control flow for those 
objects actually work. However, if we run with the "async operation 
introspection protocol" idea, then a suitably generic name would be 
`__async_call__`, and we could make it a doubly-linked list for the coroutine 
and async generator case by setting an `__async_return__` attribute on the 
target (to say where we expect control to return to when we're done).

----------
nosy: +yselivanov

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31230>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to