About __class__ of an int literal

Terry Reedy tjreedy at udel.edu
Wed Sep 29 20:46:18 CEST 2010

On 9/29/2010 8:34 AM, Hrvoje Niksic wrote:
> Steven D'Aprano<steve at REMOVE-THIS-cybersource.com.au>  writes:
>> On Wed, 29 Sep 2010 02:20:55 +0100, MRAB wrote:
>>> On 29/09/2010 01:19, Terry Reedy wrote:
>>>> A person using instances of a class should seldom use special names
>>>> directly. They are, in a sense, implementation details, even if
>>>> documented. The idiom "if __name__ == '__main__':" is an exception.
>>> __file__ is another exception.

>> As are __iter__, __next__, __add__, __dict__, and, yes, __class__, to
>> say nothing of all the other special methods.

I strongly disagree.

> I think by "person using instances of a class" Terry referred to the
> user of a class as opposed to the implementor.


>  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.

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. They are only for customizing user classes. 
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.

 >  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 

Terry Jan Reedy

More information about the Python-list mailing list