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

Anna Ravenscroft annaraven at gmail.com
Sat Mar 4 18:34:50 CET 2006

On 3/3/06, Raymond Hettinger <raymond.hettinger at verizon.net> wrote:

[Aahz] > * 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. When teaching your classes, do you sense an aversion to using double underscore methods in regular code? I sense an implied message that these methods are not intended to be called directly (i.e. the discomfort of typing x.setitem(k,v) serves as a cue to write x[k]=v instead; likewise, x.int() pushes towards int(x) instead). If so, then that is a good reason to leave it.next() as-is. Unlike setitem or int, the next() method is intended to be called directly in normal code. Of course, for-loops are the most common case and it makes no difference there; however, in the rest of the cases where the iterator is accessed directly, the current naming is clean, readable, and doesn't provide an aversive cue. The double underscore convention is appropriate where the method is always invoked magically in normal code and not called directly. The next() method is differenct because it is a mixed case, sometimes called magically and sometimes called directly. In the latter case, the name is highly visible and therefore should not have double underscores. I suspect that those who feel differently are ones who usually avoid calling next() directly. That's okay, but we shouldn't muck-up the naming for the rest of us who often do have a need to use next(). This is doubly important because we're now expanding the protocol to include send() and throw(). Adding underscores around them too will only make those methods look harder to use than they actually are. Don't underestimate the psychological revulsion to calling code filled with piles of double underscores.

I think this is a really good point. next() is supposed to get used, by coders, in regular code - so it shouldn't be next. I can understand the desire for both forms, although that seems it would clutter things up unnecessarily - particularly if the two do the same thing.

Anna -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060304/7ed63cdd/attachment.html

More information about the Python-Dev mailing list