[Python-Dev] iterator API in Py3.0

[Raymond Hettinger]

[Anna Ravenscroft]
>>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.

[Phillip Eby]
> 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 
disease.

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.



Raymond