Description

x42005e1f

opened on Jan 8, 2026

Issue body actions

Bug report

Bug description:

types.coroutine() uses _GeneratorWrapper as a wrapper for generator iterators in cases where the callable object is not a user-defined function (but is, for example, a generator function compiled via Cython/Nuitka). However, the implementation has not been updated for 11 years and therefore does not provide certain properties, such as:

• GeneratorType.gi_suspended (Python ≥3.11, bpo-46409: Make generators in bytecode #30633)
• CoroutineType.cr_suspended (Python ≥3.11, bpo-46409: Make generators in bytecode #30633)
• CoroutineType.cr_origin (Python ≥3.7, bpo-32591: Add native coroutine origin tracking #5250)

As a result, the objects returned by the new function do not look exactly like types.GeneratorType/types.CoroutineType, which in particular makes them incompatible with the inspect.getgeneratorstate() and inspect.getcoroutinestate() functions:

>>> from inspect import getcoroutinestate, getgeneratorstate
>>> from types import coroutine
>>> def generator_function():
...     return
...     yield  # generator definition
>>> @coroutine
... def coroutine_function():
...     return generator_function()
>>> gencoro = coroutine_function()
>>> getgeneratorstate(gencoro)
Traceback (most recent call last):
AttributeError: '_GeneratorWrapper' object has no attribute 'gi_suspended'
>>> getcoroutinestate(gencoro)
Traceback (most recent call last):
AttributeError: '_GeneratorWrapper' object has no attribute 'cr_suspended'

Interestingly, there was already an attempt to add *_suspended in #133373 (see #133372 (comment)), but the PR was closed in favor of removing the TODO comment, and this side issue was apparently overlooked.

Related: cython/cython#7448.

CPython versions tested on:

3.11, 3.12, 3.13, 3.14

Operating systems tested on:

Linux

Linked PRs

• gh-143552: Fix inspect.getcoroutinestate for generator-based coroutines #143609

Activity

1. x42005e1f

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Jan 8, 2026
2. aisk

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Jan 8, 2026
3. x42005e1f commented on Jan 8, 2026

   

   x42005e1f

   on Jan 8, 2026

   ContributorAuthor

   More actions

   I would add that the _GeneratorWrapper implementation itself is somewhat questionable. If we look at how generator-based coroutine objects behave, we see that they do not implement the types.CoroutineType interface (and in a sense, even the collections.abc.Coroutine interface), but only make generator iterators awaitable:

   >>> from inspect import getcoroutinestate, getgeneratorstate, isawaitable
   >>> from types import coroutine
   >>> @coroutine
   ... def coroutine_function():
   ...     return
   ...     yield  # generator definition
   >>> gencoro = coroutine_function()
   >>> getgeneratorstate(gencoro)
   'GEN_CREATED'
   >>> getcoroutinestate(gencoro)
   Traceback (most recent call last):
   AttributeError: 'generator' object has no attribute 'cr_running'. Did you mean: 'gi_running'?
   >>> dir(gencoro)
   ['__class__', '__class_getitem__', '__del__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__lt__', '__name__', '__ne__', '__new__', '__next__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'close', 'gi_code', 'gi_frame', 'gi_running', 'gi_suspended', 'gi_yieldfrom', 'send', 'throw']
   >>> hasattr(gencoro, '__await__')
   False
   >>> isawaitable(gencoro)
   True

   This difference in behavior for different types of passed callable objects may be unexpected (and is it even correct to say that generator-based coroutines are actually considered coroutine objects, as stated in the documentation?). There are three ways to deal with this:

   • Remove the cr_* properties.
   • Always use _GeneratorWrapper.
   • Make generator-based coroutines a separate type.

   The third option has been rejected (see the PR mentioned above). The second option, ironically, may not be very good in terms of performance, especially when types.coroutine() is used to yield objects to the event loop.

   ---

   Initially, _GeneratorWrapper was added in 13f7723 (see #68504; PEP 492). It did not have the cr_* properties, thus replicating only the types.GeneratorType interface (the only difference was having the __await__() method). These properties were added in 5376ba9 (see #68588; PEP 492). This was probably done by mistake.
4. VanshAgarwal24036 commented on Jan 9, 2026

   

   VanshAgarwal24036

   on Jan 9, 2026

   Contributor

   More actions

   Hi, I’ve opened a PR that fixes this issue by adding the missing coroutine introspection attributes for generator-based coroutines.
5. picnixz commented on Jan 9, 2026

   

   picnixz

   on Jan 9, 2026

   Member

   More actions

   @VanshAgarwal24036 Please wait until we decided how to proceed. It's not a trivial matter.

Issue actions