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 bbayles, erik.bray, jdemeyer, ncoghlan, rhettinger, serhiy.storchaka
Date 2018-06-24.03:50:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
(I've updated the issue title to state the design requirement, rather than one potential solution to the design requirement)

I like the declarative `__infinite_iterator__` suggestion, as that's:

1. really easy to implement when defining a custom iterator type (whether in Python or in an extension module

2. relatively easy to add to generator-iterators as a read-write property that defaults to False (which could then be set to True via an "itertools.infinite_generator" decorator)

3. relatively easy to support in iterators like map, filter, etc via a property that delegates the response to the underlying iterator

4. even more complex iterators like chain, product, and combinations would be able to define a property based on "any(itr.__infinite__iterator__ in underyling_iterators)"
Date User Action Args
2018-06-24 03:50:59ncoghlansetrecipients: + ncoghlan, rhettinger, erik.bray, serhiy.storchaka, jdemeyer, bbayles
2018-06-24 03:50:59ncoghlansetmessageid: <>
2018-06-24 03:50:59ncoghlanlinkissue33939 messages
2018-06-24 03:50:58ncoghlancreate