On 3/7/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On Tue, 6 Mar 2007, Collin Winter wrote:
>
> > I can give you warnings on the following items,
>
> > - global assignments to "next".
> > - global definitions of a "next" function.
> > - global imports of anything named "next".
> > - assignments to
On Tue, 6 Mar 2007, Collin Winter wrote:
> I can give you warnings on the following items,
> - global assignments to "next".
> - global definitions of a "next" function.
> - global imports of anything named "next".
> - assignments to "__builtin__.next".
How hard would it be to warn about any ass
On 3/7/07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Collin Winter" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | >From the checked-in version,
> |
> | """
> | Two additional transformations will be added to the 2to3 translation tool
> [3]:
> |
> |* Method definitions name
"Collin Winter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| >From the checked-in version,
|
| """
| Two additional transformations will be added to the 2to3 translation tool
[3]:
|
|* Method definitions named next will be renamed to __next__.
|* Explicit calls to the ne
On Tue, 6 Mar 2007, Collin Winter wrote:
> I'd like to strike the part about making "x.next()" ->
> "next(x)"/"x.__next__()" determined by the presence of a module-level
> "next" binding. I'd rather see the transformation always be "x.next()"
> -> "next(x)" and warn on top-level "next"s. Doing it t
>From the checked-in version,
"""
Two additional transformations will be added to the 2to3 translation tool [3]:
* 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(
