[Python-Dev] iterator API in Py3.0

Phillip J. Eby pje at telecommunity.com
Sun Mar 5 03:03:26 CET 2006


At 04:44 PM 3/4/2006 -0500, Raymond Hettinger wrote:
>>  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.
>
>Yes, that's pretty much it.  IMO, introducing __builtin__.next() would 
>suck. The sublime feeling of consistency isn't worth the cost of an extra 
>builtin and adding an unnecessary global lookup to an otherwise 
>lightweight inner-loop construct.

You mean, versus an unnecessary attribute lookup?  :)  Guido has stated 
many times that future versions of Python should be able to optimize 
references to builtins so that the global cost isn't 
required.  Optimization of attribute lookups is a bit more speculative at 
this point, and can currently involve *more* dictionary lookups than a 
global lookup, depending on the inheritance depth.  IIRC, looking for a 
'next' method on a new-style object requires a minimum of two dictionary 
accesses already: one to look in the class, and one in the instance to make 
sure it's not shadowed.  In contrast, __next__() could be a fast slot 
access, since slots are copied directly to subclasses.

(But neither the performance argument nor the "extra builtin" argument make 
sense to me anyway, since they would both apply equally to len() and iter().)



More information about the Python-Dev mailing list