About __class__ of an int literal

[Steven D'Aprano]

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