About __class__ of an int literal

[Hrvoje Niksic]

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

Obviously, none of this applies to __dict__, __class__, and friends, nor
does it apply to cases where you know what you're doing, such as
invoking __<method>__ of a superclass.

> (This may change in the future. Given type(), and isinstance(), I'm not 
> sure what value __class__ adds.)

None whatsoever.  __class__ used to be necessary to tell the appart
instances of different old-style classes:

>>> class X: pass  # old-style
...
>>> X().__class__
<class __main__.X at 0xb772f2fc>
>>> type(X())
<type 'instance'>

Now that classes produce real types, they are equivalent.