This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients Ben.Darnell, Yury.Selivanov, asvetlov, gvanrossum, ncoghlan, scoder, vstinner, yselivanov
Date 2015-06-10.16:49:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> I currently do isinstance(x, types.GeneratorType), which will fail if x
> is actually a GeneratorWrapper. I can change this to use
> when it exists, but then I'd have to have some
> conditional logic to switch between and types depending
> on what version I'm running on.

I originally planned to make the next Cython release patch the Generator
and Coroutine ABCs into, but I now think it would be worth
uploading an "abc_backports" package to PyPI instead that does that and on
which asyncio, tornado and other packages could simply depend with a

> It would be nice if that were
> encapsulated in inspect.isgenerator().

+1, code that needs exactly a generator, e.g. for "gi_running" and friends,
can still test for isinstance(obj, types.GeneratorType) in a completely
backwards compatible way, which is more explicit anyway.

> More generally, the inconsistency between isgenerator() and
> iscoroutine() is kind of odd. I would expect that either all inspect
> functions or none of them would use a suitable ABC if one exists.

Yes, it's odd. Either way would work ("types is for types only" vs. "types
includes protocols"), but having both disagree seems wrong.

I think the mere fact that there is a higher level function than
isinstance() suggests that it should really be more high level and not just
doing exactly the same for all times.
Date User Action Args
2015-06-10 16:49:22scodersetrecipients: + scoder, gvanrossum, ncoghlan, vstinner, asvetlov, Yury.Selivanov, Ben.Darnell, yselivanov
2015-06-10 16:49:22scoderlinkissue24400 messages
2015-06-10 16:49:22scodercreate