Type of an object: ‘obj.__class__’ versus ‘type(obj)’
steve at pearwood.info
Tue Dec 17 08:42:35 CET 2013
On Tue, 17 Dec 2013 08:14:09 +0100, dieter wrote:
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> On Mon, 16 Dec 2013 12:51:21 +1100, Ben Finney wrote: ... "type(obj)"
>> versus "obj.__class__" That is an excellent question, I only wish I had
>> an excellent answer to give you. Obviously great minds think alike
>> because I was going to ask the same question, prompted by this comment
>> from Nick Coghlan on the python-dev list:
>> "...type(obj).__name__ (working with the concrete type, ignoring any
>> proxying) or obj.__class__.__name__ (which takes proxying into
>> So there is a difference between them, but I'm not entirely sure what
>> it is.
> I understand the difference: sometimes you work with proxies (e.g.
> "weakref" proxies). A proxie should work mostly like the proxied object
> - but in rare cases, you want to detect that what you have is actually a
> proxie rather than the real object. You can use "type(obj)" to check the
> real type ob "obj" (in some sense, it is more direct - more reliable;
> giving you the real type of "obj"). "obj.__class__" on the other hand
> uses standard attribute access - and proxying may have customized
> attribute access to access the proxied object's attributes rather than
> its own: then "obj.__class__" would give you not the type of "obj" (the
> proxie) but that of the proxied object.
I think I need to see an actual working demonstration, because as far as
I can see, type(obj) returns obj.__class__.
I'm not suggesting you are wrong, only that code speaks more loudly than
More information about the Python-list