[Python-Dev] iterator API in Py3.0
raymond.hettinger at verizon.net
Sat Mar 4 22:11:17 CET 2006
>>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.
> By this argument, we should be using ob.len() instead of len(ob), and
> ob.iter() instead of iter(ob).
Hey, no fair misstating her argument and then reducing it to the absurd. We're
all aware that __len__ and __iter__ are supported by a wide variety of object
types and are accessed through builtin functions provided expressly for that
purpose. In contrast, we're all aware that next() applies only iterator
objects, that it was designed for both direct and magic invocation, and that
there is no corresponding builtin.
This conversation is getting goofy. There is no underlying problem to be
solved. Essentially, a couple of developers feel irritated by a perceived
aberration from a naming convention. To assuage that irritation, they are
willing to either 1) inflict pain on direct callers by cluttering the calling
code with pairs of double underscores, or 2) add yet another builtin (needlessly
bloating the namespace, adding another level of indirection, and burdening
execution with an unnecessary global lookup). The cure is worse than the
IMO, the appropriate solution is to amend your understanding of the naming
convention to only apply to methods whose normal invocation is exclusively magic
and not called directly.
More information about the Python-Dev