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().) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
