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

[Thomas Wouters]

On 3/6/07, Ka-Ping Yee <python at zesty.ca> wrote:
>
> On Tue, 6 Mar 2007, Neil Schemenauer wrote:
> > The argument that all "protocol" methods should have double
> > underscore names seems to be pretty weak too.  It's only an appeal
> > for consistency, I think.  We don't suggest that file-like objects
> > should implement __read__() instead of read(), for example.
>
> There is a convention and it is applied quite consistently:
>
>     Double-underscores are for methods implicitly invoked
>     by a language construct.


I believe you misinterpret the convention. Rather, as I see it, it is:

    Double-underscores are for methods implicitly invoked
    by a language construct, and should not be called
    directly on foreign objects.

(So perhaps it's not much of a convention, if we can't agree on it :) The
__*__ methods can be seen as a private API. 'next' is not part of it. I see
no problem what so ever with the interpreter calling a non-underscored
function. I do not understand why this is a problem.

I'm -1 on the change. I would be -0 (*maybe* +0) if I thought we had a
chance in hell of doing this migration gracefully, but we don't. The
translator can't really handle all the cornercases we currently have. The
best we can do is *add* a __next__ method to classes that have a next method
but no __next__ method, and I simply do not think that's worth it. I am not
convinced there is an *actual problem* we are solving, other than that some
people are confused about the current situation. Other people would be
confused if it was different, so I do not subscribe to the validity of that
argument. The single reason I like the builtin next() is the two-argument
version, which is quite similar to the two-argument iter(). I would prefer
adding it *without* renaming .next to .__next__.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070306/461ddf34/attachment.html