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

[Cameron Laird]

In article <1271354562-2632983 at hypernet.com>,
Gordon McMillan <gmcm at hypernet.com> wrote:
			.
			.
			.
>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 
			.
			.
			.
>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.
			.
			.
			.
>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).
			.
			.
			.
Thanks.  Our current status is therefore that all
known demands for introspection-goop either
1.  can be satisfied by __*__ references,
    which we all recognize as slightly out-
    side normal operations, or
2.  are the result of a misdesign for which
    we can exhibit a superior alternative,
    often involving disciplined polymorphism
    or an interface from an explicit class
    definition.
This feels slightly alien to me, but I can get over
it.  I think it's particularly valuable to write up
explanations of the form, "If you find yourself
wanting to XX, take it as a hint to study your design
in search of a YY, which will yield a better design."
-- 

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