[Python-Dev] iterator API in Py3.0

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.

-------------- 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