"What is the name of the function/method that called me?"

[Gordon McMillan]

[Cameron] 
>> Is there a profound and/or interesting     
>> reason Python doesn't provide the kinds 
>> of introspective features we're discus- 
>> sing here (a traceback, for example) 
>> without the detour through the land of 
>> exception-tossing? 
[Moshe]
> Yes.
> It is a reminder that IT SHOULDN'T BE DONE (sorry for shouting).  
> Introspecting into
> "static" stuff (like classes, methods, etc.) is
> /moderately/ ok (though it is usually more a sign the
> design was wrong). 
[Juergen A. Erhard]
> I strongly disagree here.  Introspection is
> surely not as evil as you make it to be.  

I don't think Moshe was saying introspection is evil. I'd put it 
this way: Python without double-underscore stuff is safe as 
Mommy's milk. Python with double-underscore stuff is riskier 
(tends to stack overflow unexpectedly), but still sanctioned, 
approved and so documented. But when you get into throwing 
exceptions so you can pull apart the traceback, you're on your 
own. This is implementation detail stuff, and if your code 
breaks under a new release, it's your problem, not Python's.

[Cameron]
> Interesting arguments.  There certainly seem to be
> plenty of respected people in the C++ world who believe run-time
> type information is valuable.  Do you, Mr. Zadka, generally
> suspect their designs are wrong?  I'm willing to consider that
> possibility.

Some C++ column I read recently said that the C++ 
committee members (who, of course, approved RTTI) were 
informally discussing this and could not find an example of 
RTTI usage that wasn't better done without RTTI.
    .

[Cameron]
> Enough of this abstraction.  Let's
> present concrete cases, and see whose
> position is "for-real".
> 
> Mr. Zadka, is your point that there's
> no place in the requirements specifica-
> tion of a user application for the
> kinds of information available through
> introspection?  This supposes Python
> is a language somewhat like Pascal or
> COBOL:  targeted for application writers,
> who can be protected from the obscurities
> debugger writers must negotiate.

That's Python without double-underscores.
 
> Even if we stick to userland applications,
> and deny Python a "systems" role, examples
> like Scheme show it's possible to have a
> healthy tradition of application-oriented
> idioms which rely on code-data dualities.
> I'm a tiny bit surprised, in fact, that
> Python programs "eval" as little as they
> do.  I'll conjecture, again, that there
> might be some deeper reason that this is
> so.  Generalized appeals to propriety,
> though, seem to me misplaced.

Eval isn't needed very often. Assuming (pretty safely, I think) 
that the unknown code in question follows at least some kind 
of expected interface, it is both safer, easier, and more 
comprehensible to do something like:

 mod = __import__(<unknown>)
 mod.doYourThing()

(and there are other, safer ways to do most of the other uses 
of eval).

> I can accept that object-orientation's
> traditions of polymorphism and so on are
> supposed to answer all the questions
> introspection answers.  I don't agree,
> but I understand the position.  Is that
> Python's story?  It's OO, and simply has
> no place for that dirty stuff, except in
> "debuggers"?  To me, that's at odds with
> docstrings, self-testing definitions,
> and other habits which Python justly
> boasts.

The major thing I see pulling apart tracebacks used for is 
answering "who called me". I tend to agree with Moshe here - 
it's either none of your business, or, if it _is_ your business, 
then require the caller to pass in that info. Otherwise, it's 
debugger-level stuff and doesn't belong in release code.

(Note that 1.5 added some stuff so that pulling apart 
tracebacks was no longer needed to get some kinds of info).

- Gordon