[Python-Dev] iterator API in Py3.0
Phillip J. Eby
pje at telecommunity.com
Sat Mar 4 22:27:15 CET 2006
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. :)
More information about the Python-Dev
mailing list