[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in

[Phillip J. Eby]

At 10:48 AM 3/5/2007 -0800, Guido van Rossum wrote:
>I fear that the optimizations
>we've implemented for calling tp_next (especially for built-in
>iterators like list or dict iterators). Since tp_call must be usable
>in other contexts, and has much more optional features, it will be
>hard to carry these optimizations over.

Ah...  I sense an opportunity disguised as a problem.  :)  How about we add 
a tp_call0 slot for fast zero-argument calling?  This could be the first 
step towards general IronPython-style NxN call dispatch optimization.

There are probably some interesting problems to be solved there, but the 
payoff could be broader.

I suspect we would actually want to also implement a tp_call1 (and maybe a 
tp_call2), because we would want e.g. method objects' tp_call0 to forward 
to the tp_call1 of their im_func.

For the greatest optimization payoff, of course, we would need to support C 
function/method types that support this convention.

Once there's a manual implementation for N up to say, 2, then we could 
script some code generation to do the permutations up to some reasonable 
number.

This idea is of course independent of what happens with iterators, but 
perhaps Raymond will be more incentivized to take on this particular 
optimization challenge if it will weigh in favor of dropping next().  :)