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 ncoghlan
Recipients Ben.Darnell, Yury.Selivanov, asvetlov, gvanrossum, martin.panter, ncoghlan, scoder, vstinner, yselivanov
Date 2015-06-20.07:31:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
My view is that the "gi_*" prefixed attributes are the ducktyped representation of whether an object is a generator-iterator or a coroutine. With the change, it means "hasattr(obj, 'cr_running')" is to "hasattr(obj, 'gi_running') as "isinstance(obj," is to "isinstance(obj,".

The main lesson I personally learned from our experience with PEP 342 is that generator-as-iterator and generator-as-coroutine are fundamentally different concepts, and that having them *look* similar on the surface turned out to be inherently confusing.

I see PEP 492 as the natural consequence of that perspective: from an eval loop perspective, native coroutines and generators-as-coroutines remain essentially interchangeable, but on the surface, they'll now look *completely* different. That allows folks to learn them as two distinct concepts (generator-iterator and coroutine), and defer (perhaps indefinitely) the realisation that they share a common underlying foundation.

Originally we were happy to let that distinction be purely syntactic, and still let the underlying implementation details leak through in the object model. This issue helped highlight that that approach was likely to prove to be a recipe for hard to debug problems as we tried to figure out where we were dealing with generator-iterator objects, native coroutine objects and generator-as-coroutine objects.
Date User Action Args
2015-06-20 07:31:58ncoghlansetrecipients: + ncoghlan, gvanrossum, scoder, vstinner, asvetlov, Yury.Selivanov, Ben.Darnell, martin.panter, yselivanov
2015-06-20 07:31:58ncoghlansetmessageid: <>
2015-06-20 07:31:58ncoghlanlinkissue24400 messages
2015-06-20 07:31:57ncoghlancreate