[Python-Dev] iterator API in Py3.0

[Phillip J. Eby]

At 04:11 PM 3/4/2006 -0500, Raymond Hettinger wrote:
>[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.

I didn't misstate her argument or reduce it to the absurd.  I simply 
applied that argument consistently to similar features of Python.  It's you 
who is concluding that this results in absurdity; I made no such 
conclusion.  I'm simply pointing out that in 3.0 we should be 
consistent.  Either we should have ob.iter() and ob.len(), or else we 
should have a builtin next().


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

You have it backwards.  If those things are so important as to be the 
deciding factor, we should add .len() and .iter() methods in 3.0 and use 
them instead of the len() and iter() functions.

Personally, I prefer functions to methods for these kinds of 
language-defined operations, but that has nothing to do with the issue of 
consistency.  As far as I can understand your position, you seem to be 
arguing that whatever we have now is correct, and therefore changing it 
would be wrong.  That is, since we use .next() now, this is correct by 
definition and a change to next() + __next__ would therefore be wrong.  And 
*that* is the only "goofy" thing I see going on here.  :)