On Wed, Mar 01, 2006, Raymond Hettinger wrote:
>
> 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.
OTOH, there is a final comment that choosing next() was perhaps a
mistake that cannot be rectified. However, it can certainly be fixed in
Python 3.0.
My argument in favor of switching to __next__() is rather simple:
* As a writer/teacher, I want to be able to say, "All Python special
methods have leading and trailing double-underscore." Period, end of
story.
* As a programmer, I want special methods to be VISIBLE. Python is a
language for reading code.
* Finally, as a debater in the future of the Python language, I don't
want any time taken up discussing whether any future special method
should get the same kind of special treatment we've given to next().
As for your point about efficiency, I don't much care whether we get a
built-in next() function, but I think that anyone who is concerned about
efficiency should do
next = obj.__next__
which saves an attribute lookup, too. I still think the vast majority of
cases will stick with for loops that automatically call __next__()
directly.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
