Re: Add user defined __eq__ to itertools.cycle class
Yep, thanks for the explanation! After some more research into this it appears this exact situation is accounted for within the `SQLAlchemy` library (reference: https://github.com/sqlalchemy/sqlalchemy/issues/5810)! Additionally, due to the complications brought up in this thread it seems like it's probably best to leave `__eq__` as the default implementation. Thanks for expanding my knowledge and Happy New Year! 🎊 Andres On Thu, Dec 31, 2020 at 4:40 PM Rob Cliffe <rob.cliffe@btinternet.com> wrote:
You bring up a good point regarding how to determine iterable equality. For example, with your last example, I had no idea that the same iterable behavior could produce radically different results between cyclers. To be quite honest, I don't really understand what causing this quirky behavior. Assuming that you refer to Steven D'Aprano's example:
I didn't understand it either until I played with it a bit. If I remember correctly it started something like this:
it = iter([1,2,3]) a = cycle(it) b = cycle(it)
Now cycle() reads elements from the iterator until it is exhausted, meanwhile storing them. Then it cycles through the stored copies. The problem is that a and b point to the *same* iterator and interfere with one another. So:
next(a) # gets 1 from 'it', stores 1, and returns 1 next(b) # gets 2 from 'it', stores 2, and returns 2 next(a) # gets 3 from 'it', stores 3, and returns 3
Now the iterator is exhausted. So subsequent calls of next(a) will cycle through a's stored elements, viz. 1 and 3. Subsequent calls of next (b) will repeat b's only stored element, viz 2.
If instead we wrote:
a = cycle(iter([1,2,3])) b = cycle(iter([1,2,3]))
then although a and b *don't* refer to the *same iterator*, they *will* behave identically.
It seems to me that this makes trying to define "equality" of cycles problematic.
Happy New Year Rob Cliffe
Link is broken :/ It should be https://github.com/sqlalchemy/sqlalchemy/issues/5810
participants (1)
-
Andres Torres