Message320350
(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:59 | ncoghlan | set | recipients:
+ ncoghlan, rhettinger, erik.bray, serhiy.storchaka, jdemeyer, bbayles |
2018-06-24 03:50:59 | ncoghlan | set | messageid: <1529812259.34.0.56676864532.issue33939@psf.upfronthosting.co.za> |
2018-06-24 03:50:59 | ncoghlan | link | issue33939 messages |
2018-06-24 03:50:58 | ncoghlan | create | |
|