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