[Python-3000] PEP: rename it.next() to it.__next__(), add a next() built-in
thomas at python.org
Tue Mar 6 12:19:26 CET 2007
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-3000