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

[Cameron Laird]

In article <22101999.3 at sanctum.jae>, Juergen A. Erhard <jae at ilk.de> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>>>>>> "Moshe" == Moshe Zadka <moshez at math.huji.ac.il> writes:
>
>    Moshe> [Posted and CCed to author]
>    Moshe> On 17 Oct 1999, Cameron Laird wrote:
>
>    >> 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
Ouch.  It's taken me several days to
get my hearing back.  I'm rather sen-
sitive to shouting.
>    Moshe> shouting).  Introspecting into "static" stuff (like
>    Moshe> classes, methods, etc.) is /moderately/ ok (though it is
>    Moshe> usually more a sign the design was wrong).
>
>I strongly disagree here.  Introspection is surely not as evil as you
>make it to be.  Objective-C, for example, has complete introspection
>into the static side of things...
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.
			.
			.
			.
>    Moshe> However, introspecting into /dynamic/ data should be
>    Moshe> available (because the debugger needs it) but obscure
>    Moshe> (because anyone doing this for the runtime of his program
>    Moshe> is commiting a shooting offense). If someone needs this
>    Moshe> information to debug his program, they should use the
>    Moshe> debugger.
>
>I also disagree, though not as strongly as above.  But again, just
>because you don't see a need for this doesn't mean it can't be used in
>a meaningful way.
			.
			.
			.
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.

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.

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.
-- 

Cameron Laird           http://starbase.neosoft.com/~claird/home.html
claird at NeoSoft.com      +1 281 996 8546 FAX