On Wed, 29 Sep 2010 14:46:18 -0400, Terry Reedy wrote:
>> In that sense the user
>> should be calling iter(foo) instead of foo.__iter__(), next(foo)
>> instead of foo.__next__(), and foo+bar instead of foo.__add__(bar).
>
> Yes. Guido added iter() and next() to the list of built-in functions,
> even though they seem reduncant.. I believe it is his intention that the
> use of special names outside of class statements should be fairly rare.
Fairly rare but not non-existent.
For example, there's nothing wrong with using a callback function of
(say) instance.__sub__ instead of lambda b, a=instance: a - b. Not only
is the direct call to the method slightly faster, but more importantly
it's easier to read and more clear to intent.
Admittedly beginners may find instance.__sub__ to be a tad mysterious,
but then beginners are likely to find the lambda form with its two
arguments and default value mysterious too.
> If I remember right, in the old, pre-2.2 system that separated built-in
> types and user-written classes, the builtins did not have accessible
> special method attributes.
Yes, that's correct. But we're talking about Python *now*, not back in
the mists of time before new-style classes. Would you argue that users
shouldn't use decorators, iterators or closures because Python 2.1 didn't
have them? I don't think so.
> They are only for customizing user classes.
Say "were" rather than "are" and I will agree with you.
Say "primarily for" rather than "only" and I will also agree with you.
> So one could not have generically written foo.__add__(bar).
> Special-method attribute were added to builtins so that they could be
> inherited (or replaced) by user-written subclasses, not so that one
> could replace normal syntax.
Of course one shouldn't prefer seq.__len__() over len(seq). But that's a
readability issue, and not because Python implementations are free to
change __len__ to something else.
If I gave the opposite impression, that was not my intention and I'm
sorry for the failure to be more clear.
>> Direct
>> calls to special-name methods, such as __len__, often indicate that the
>> programmer hasn't grasped how those methods are intended to be used in
>> Python.
>
> Right. That fact that *Python* interpreters implement syntax with
> special methods is an implementation detail of the *language*. The
> importance is that it allow *writers* of new classes to rather easily
> imitate built-in classes so that their classes seamlessly plug into the
> syntax.
If I've understood this paragraph correctly, you're trying to say that
since *other languages* that aren't Python are free to implement syntax
features using some other mechanism, *Python* developers shouldn't use
special methods because they are implementation details.
If we're prohibited from using anything which is an implementation detail
of "the *language*" (your emphasis), then we can't use *anything*. Yes,
special methods are an implementation detail of Python, but only in the
same sense that it is an implementation detail of Python that we write
this:
def f(a, b):
x = a + b
return math.sqrt(x)
rather than this:
function f(a, b: integer):float:
var
x: integer;
begin
x := a + b;
f := sqrt(x)
end;
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
