On Wed, Sep 15, 2021 at 08:57:58AM -0700, Guido van Rossum wrote: [...]
Yes, we all understand that. The reason I invoked "duck typing" is that as long as you don't use the iterator in a situation where iter() is called on it, it works fine. Just like a class with a readline() method works fine in some cases where a file is expected.
Okay, you've convinced me that perhaps duck typing is an appropriate term to use. But I hope we wouldn't be arguing that a class with only a readline() method *is* a file object and changing the docs to support that view :-) [...]
No-one is arguing that an iterator that doesn't define __iter__ is great.
I'm arguing that it's not an iterator at all, even if you can use it in place of an iterator under some circumstances. As you pointed out, there is already a name for that: iterable.
And the docs should continue to recommend strongly to add an __iter__ method returning self.
Agreed. That's part of the iterator protocol. If some objects don't need to support the full iterator protocol in order to get the job done, then that's great, and people should be allowed to support only the part of the protocol they need.
My only beef is with over-zealous people who might preemptively want to reject an iterator at runtime that only has __next__; in particular "for" and iter() have no business checking for this attribute ("for" only needs __next__, and iter() only should check for the minimal version of the protocol to reject things without __next__).
Again, I agree. `for` and iter() should only check for the minimum of what they need.
I believe that iterable objects that define `__next__` but not `__iter__` are fundamentally broken. If they happen to work in some circumstances but not others, that's because the iterator protocol is relaxed enough to work with broken iterators :-)
Your opinion is loud and clear. I just happen to disagree.
I think we're in violent agreement here :-) Obligatory Argument Sketch video: https://www.youtube.com/watch?v=ohDB5gbtaEQ -- Steve