On Wed, 17 Jul 2002, Guido van Rossum wrote:
the method "next" means that any object with a "next" method cannot be adapted to support the iterator protocol. Unfortunately "next" is a pretty common word and it's quite possible that such a method name is already in use.
Can you explain this? Last time I checked CVS, PEP 246 wasn't implemented yet, so I don't think you mean "adapted" in that sense.
No, i didn't -- i just meant in the more general sense. To make an object support one of the other internal protocols, like repr(), you can just add a special method (in Python) or fill in a slot (in C).
Generally speaking, iterator implementations aren't created by making changes to an existing class
Well, i guess that's part of the protocol philosophy. There exist cursor-like objects that would be natural candidates for being used like iterators (files are one example, database cursors are another). Choosing __next__ makes it possible to add support to an existing object when appropriate, instead of requiring an auxiliary object regardless of whether it's appropriate or inappropriate. To me, the former feels like the more typical Python thing to do, because it's consistent with the way all the other protocols work. So it's from this perspective that "next" without underscores is a wart to me. For example, when something is container-like you can implement __getitem__ on the object itself, and then you can use [] with the object. Some objects let you fetch containers and some objects implement __getitem__ on their own. But we don't force everybody to provide a convert-to-container operation in all cases before allowing them to provide __getitem__. -- ?!ng