On Tue, 17 Dec 2013 08:14:09 +0100, dieter wrote: > Steven D'Aprano <steve+comp.lang.pyt...@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 >> account)..." >> >> 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 words :-) -- Steven -- https://mail.python.org/mailman/listinfo/python-list