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 rhettinger
Recipients alex, amaury.forgeotdarc, arigo, benjamin.peterson, ezio.melotti, georg.brandl, python-dev, rhettinger, serhiy.storchaka
Date 2019-08-24.04:43:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> It's just one of many places where CPython does a recursion 
> without checking the recursion depth.  CPython still works, 
> based on the resonable assumption that doing such a recursion
> here is obscure.

I agree with that assessment and am going to close this as something we can live with (or least have lived with successfully for a long time).  AFAICT, this situation doesn't arise in practical code.

It is possible to slow down the language by adding a variant of recursion checks to every call to an iterator.  But this just makes the language pay a code complexity cost and performance cost for something that doesn't really affect real users.  People typically choose itertools for their speed (otherwise, plain generators can be clearer).  We shouldn't work against the needs of those users.

A robust, clean, and performant solution wouldn't be easy but would likely involve some general purpose stack overflow protection that periodically makes sure there is enough stack remaining for C Python to function correctly.
Date User Action Args
2019-08-24 04:43:08rhettingersetrecipients: + rhettinger, arigo, georg.brandl, amaury.forgeotdarc, benjamin.peterson, ezio.melotti, alex, python-dev, serhiy.storchaka
2019-08-24 04:43:08rhettingersetmessageid: <>
2019-08-24 04:43:08rhettingerlinkissue14010 messages
2019-08-24 04:43:08rhettingercreate