[Python-Dev] iterator API in Py3.0
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.
> 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.
More information about the Python-Dev