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 <tjre...@udel.edu > <mailto:tjre...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
