About __class__ of an int literal
hniksic at xemacs.org
Wed Sep 29 14:34:33 CEST 2010
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
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
<class __main__.X at 0xb772f2fc>
Now that classes produce real types, they are equivalent.
More information about the Python-list