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

   Last edited by x42005e1f

   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.