Why not 3.__class__ ?

[James_Althoff at i2.com]

Tim Peters wrote:
>They're supposed to be ugly:  if you find yourself using __xxx__ thingies
a
>lot, it's supposed to be a clue that you're not using the language as
>intended.

Point taken.  (In his defense, he reminds the jury that he *did* end his
remark with a "full wink").

BTW, I've just written a Jython-based debugger-type thingie that provides a
GUI in which you (our developers, that is) can visually inspect all fields,
methods, base classes, etc. for any object (including Java instances,
Python builtin objects, class objects, etc.) in any of our applications
(whilst it -- the application -- is running).  Moreover you (the developer,
again) can change (using the GUI) any field value on the fly (or add or
delete same).  And, most importantly, you can rewrite a method on the fly
(using the GUI) -- restricted to Python methods, of course, not for Java
methods because Java is less dynamic and, hence, quite inferior to Python
in this regard -- and the affected instances of the affected class (that
owns the changed method/function) start using the new method definition
without restart of said application and without re-instantiation of said
instances.  Also included is a GUI for pdb which allows pdb to actually
*work* with Jython even after the Swing event queue starts running
(out-of-the-box pdb *doesn't* work with Swing).  Our developers have found
this stuff to provide a nice boost in their (already high because of
Jython) productivity.  All of this, of course, is made possible because of
the wonderful, dynamic nature of Python (three cheers!).  But the point is,
accessing __class__ (not to mention __bases__, __name__, __dict__,
func_code, func_globals, etc.) is something I need to do a lot for this
type of deal.  I hope, then, that this is *not* a case of "not using the
language as intended". <wink>  <NOTE> a wink is included ;-) </NOTE>

<snip>
>No, but it *is* the part of your brain hardwired to Smalltalk that avoids
>functions as if they were somehow inscrutable <wink>.  The alternative
>type(0), type([]), type('') etc are the intended ways to find the type of
an
>object.  More unfortunately than not, all classes in 2.1 had the same
type,
>as did all class instances.  "Healing the type/class split" is what 2.2
>starts to take seriously, although isinstance(x, type(0)) was forced into
>working several releases ago.

Thanks.  I can use that!  (He repeats to himself as he codes, tense and
white-knuckled: "functions are not evil, functions are not evil, functions
are not evil, . . .").

Jim