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

[Terry Reedy]

"Ka-Ping Yee" <python-dev at zesty.ca> wrote in message 
news:Pine.LNX.4.58.0703041845250.11751 at server1.LFW.org...

On the consistency argument: sorted(somelist) calls copy(somelist).sort, 
not copy(somelist).__sort__.   But I don't expect to see this change 
proposed.

| Transition Plan
| ===============
|
| Two additional transformations will be added to the 2to3 translation
| tool [2]_:
|
| *   Method definitions named ``next`` will be renamed to ``__next__``.

Consistently renaming 'next' to '__next__', including at call sites, would 
be one thing...  As explained below, you *must* translate at least non-call 
name lookups to not break programs.

| *   Explicit calls to the ``next`` method will be replaced with calls
|    to the built-in ``next`` function.  For example, ``x.next()`` will
|    become ``next(x)``.

But this is something else -- a de-optimization.

One of the virtues, and as I recall, design purposes, of .next calls is to 
be fast.  After the first call, execution jumps directly into the 
pre-existing stack frame.  This change would interpose a regular old slow 
call process, thereby undoing this speedup (relative to the older 
.__getitem__ protocol).  The next 'method' is uniquely intended to be 
called repeatedly, even billions of times, on the same instance, with the 
same args (none).  So it should be as fast as possible.

It is also useless for a large class of explicit uses.

Explicit calls are usually done within a while loop.  It is then fairly 
standard to factor out the attribute lookup with with 'xnext = x.next' or 
'xnext = genx(args).next' before the loop and use the bound method within 
the loop.  (I presume the for loop machinery does the same.)

* So the translation tool must also change the name to '__next__' in such 
attribute lookups.

Terry Jan Reedy