[Python-ideas] Membership of infinite iterators

[Michel Desmoulin]

Given that:

- it doesn't break anything;
- the behavior makes sense;
- it can avoid the machine freezing when one is not careful;

It can be a good idea.

Those generators could have iterators that are not themselves and have a
__contains__ method behaving accordingly.

I only did the mistake of using "in" on those once, but it did happen. I
can imagine everybody do the same at least once. It's not a huge help,
but the joy of using python is a collection of small things after all.

Le 17/10/2017 à 05:27, אלעזר a écrit :
> 
> 
> בתאריך יום ג׳, 17 באוק׳ 2017, 00:13, מאת Terry Reedy ‏<tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>>:
> 
>     On 10/15/2017 9:12 PM, Jason Campbell wrote:
>     ...  
>     > itertools.cycle could use membership from the underlying iterable
> 
>     If the underlying iterable is an iterator, this does not work.  You
>     could define a Cycle class that requires that the input have
>     .__contain__.
> 
>     > itertools.repeat is even easier, just compare to the repeatable
>     element
> 
>     Again, create a Repeat(ob) class whose .__iter__ returns repeat(ob) and
>     that has .__contains__(x) returning 'x == ob'.
> 
>     > Does anyone else think this would be useful?
> 
>     itertools is not going to switch from iterators to non-iterator
>     iterables.
> 
> 
> It doesn't have to switch, and does not have to _require_ the input to
> define __contains__ method for the proposal to be meaningful. It can
> work with the same kind of iterables as its inputs, delegating whenever
> possible. I'm sure there are good reasons not to do it, but that's not
> an either/or decision.  
> 
> Elazar 
> 
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>