Why not 3.__class__ ?

Tim Peters tim.one at home.com
Fri Oct 12 02:46:47 CEST 2001

[Tim, on __xxx__ names]
> 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.

[James_Althoff at i2.com>]
> Point taken.  (In his defense, he reminds the jury that he *did* end his
> remark with a "full wink").

Sure -- I didn't end mine with a skull and crossbones either <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
> ...
> Moreover you (the developer, again) can change (using the GUI) any field
> value on the fly (or add or delete same).  And ... you can rewrite a
> method on the fly (using the GUI)
> ...
> 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>

No problem, that level of internal detail is exposed precisely so that
debuggers and browsers and profilers and compilers and disassemblers (etc)
can be written in Python.  Language meta-tools are very specialized
applications, though, tackled by few and mastered by fewer.  You'll have to
use every __xxx__ thing there is in the end, and in 2.2 I expect you're
actually going to find it harder than ever, because the new stuff is in
addition to all the old stuff (e.g., instances of "old style" classes still
all have the same type in 2.2, but instances of "new style" classes do not;
and you're also going to have to worry about static classes vs dynamic
classes, and dict-based namespaces vs slot-based, and static and class
methods in addition to "regular old methods", and computed attributes, and
custom metatypes changing method resolution order behind your back, and on &

But the need for an end-user who's simply programming in Python-- not trying
to extend or dissect it --to even think about writing 3.__class__, is
non-existent.  The handful of wizards working on meta-tools can learn to use
parentheses, else I strongly doubt their mental capacities are adequate to
the tasks they've tackled <wink>.

> ...
> (He repeats to himself as he codes, tense and white-knuckled: "functions
> are not evil, functions are not evil, functions are not evil, . . .").

Think of them as methods spelled backwards and you'll be fine.

    proves-they're-not-terrorists-ly y'rs  - tim

More information about the Python-list mailing list