[Python-Dev] iterator API in Py3.0 (original) (raw)

Raymond Hettinger raymond.hettinger at verizon.net
Wed Mar 1 06:43:06 CET 2006

-1 on the silly renaming to next and adding builtin.next(). We have len() because it applies to many different object types. In contrast, next() would apply only to iterables.

[Greg Ewing]

And you don't think there are many different types of iterables?

Um, I meant iterators and suspect you meant the same -- iow, objects returned by iter(x) that are currently guaranteed to support iter() and next() methods (i.e. generator-iterators, not the generator-functions that create them).

So the reason I'd like to see this changed in 3.0 is not because of consistency for its own sake, but because it would provide a better basis for future development.

YAGNI. The hypothetical "future development" benefit is even more specious than the appeal for consistency. Let's try to resist mucking-up this simple, elegant, and fast iterface by adding another level of indirection. I'm strongly -1 on this proposal and will likely remain so until shown demonstrable benefits for real use cases that are compelling enough to warrant cluttering and slowing the iterator interface.

I usually let this sort of thing slide, but the iterator API is too important for trivial, incompatible, and damaging changes. Looking back at Guido's original rationale for naming the method next() instead of next(), http://www.python.org/peps/pep-0234.html , it does not look like any of those reasons will cease to apply in Py3.0.

If you want a next() function, it is trivial to write your own pure Python version and leave the API unmolested for everyone else. Since it is already possible to write such a function, I'm curious whether you've had occasion to do so in real code and whether it provided any benefits in terms of consistency or future development flexibility. Most likely, the answer is no. That should be a good indicator that the proposed benefits are illusory.

Raymond

More information about the Python-Dev mailing list