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

Collin Winter collinw at gmail.com
Tue Mar 6 18:43:26 CET 2007

On 3/5/07, Collin Winter <collinw at gmail.com> wrote:
> On 3/5/07, Ka-Ping Yee <python-dev at zesty.ca> wrote:
> [snip]
> > Transition Plan
> > ===============
> >
> > Two additional transformations will be added to the 2to3 translation
> > tool [2]_:
> >
> > *   Method definitions named ``next`` will be renamed to ``__next__``.
> >
> > *   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)``.
> >
> > If the module being processed already contains a top-level function
> > definition named ``next``, the second transformation will not be done;
> > instead, calls to ``x.next()`` will be replaced with ``x.__next__()``
> > and a warning will be emitted.
> The basic transformations for this are (relatively) easy to implement.
> Basing the second transformation on the absence of a top-level
> function definition (don't forget assignments and imports!) for
> "next", though, is going to require some surgery to 2to3's internals.
> I'll see what I can do.

Preliminary results:

After playing around with 2to3 for a while, it doesn't seem possible
to base the second transformation on the presence of a top-level
"next" binding. I can detect the binding's presence and warn about it,
but just not in time to impact the "it.next()" -> "next(it)"
transformation. I'm tinkering with an implementation that defers the
transformation until 2to3 has finished walking the entire tree, but
it's a lot of clutter and hackery for something like this.

Collin Winter

More information about the Python-3000 mailing list