On 3/6/07, Ka-Ping Yee <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe: 
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

Reply via email to