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