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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4