On Sun, Nov 28, 2021 at 04:40:15PM -0800, Christopher Barker wrote:
Sure, but I"m not sure it's THAT much harder to say:
If you want to make an iterator, define a __next__ method.
Just for the record, that's not what makes an iterator. That makes a half-and-half something almost but not quite an iterator :-) To be an iterator, your object needs: 1. a `__next__` method which returns the next value; 2. and an `__iter__` method which returns self. Also we do often use the term "iterator" informally to refer to objects which have an `__iter__` method which returns an iterator.
If you want to make a ChainableIterator, derive from abc.ChaibableIterator -- it will give you some nifty stuff for free.
Pythonistas: "Duck typing for the win! You shouldn't care about inheritence, protocols are better!" Also Pythonistas: "Just inherit from X." *wink*
And some of the current ABCs do provide some out of the box functionality right now.
It would take someone other than me to explore this idea further, I'm not sure I even want it. But it struck me that one of the reasons we don't want to add functionality to existing ABCs is that it would suddenly make other types that currently conform to the ABC, but don't derive from it, no longer valid. ANd with the proliferation of type checking, that would be a mess.
I think that is correct.
But if we create a new ABC that extends an existing protocol, it wouldn't break anything.
Except that way leads to a thousand ABCs, which is another sort of chaos: - Container - Container_With_Spam - Container_With_Spam_Eggs - Container_With_Spam_Eggs_DoubleSpam_and_Spam - Container_With_Spam_Eggs_DoubleSpam_and_Spam_and_Cheese - Container_With_Spam_Eggs_DoubleSpam_and_Spam_and_Cheese_Without_Eggs -- Steve