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

[Neel Krishnaswami]

Cameron Laird <claird at starbase.neosoft.com> wrote:
>
> 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.

You answer your own question here. eval is rarely used in Python
because it is rarely useful. Even in Perl, where there was once very
extensive use of eval, it was only used to get around misfeatures of
the language (eg, to fake exceptions and first-class regexps). And
Perl has since grown so it's no longer needed in those roles.

"eval" is rarely useful because interpreting strings as programs is
basically the wrong thing to do. A program is a highly structured data
structure, and a string isn't. So it's quite difficult to build up a
program from pieces. To do it right, you need to build a parse tree
and then walk it to generate the code to give to eval. This is so much
work it's rarely worth the effort. 

In the Lisp family of languages, eval is much more useful because you
are not treating programs as strings -- you are treating source code
as a data structure. This means that generating programs from smaller
pieces is a much easier task.

But note that eval is hardly ever used in Scheme and CL anymore,
either. The same source-code/data-structure that makes using eval
in nontrivial roles makes building more specific mechanisms feasible. 
That is, you can use the Scheme or CL's macro system to add the 
language features that you need in a structured fashion. This is 
safer, more convenient, and more efficient that blindly using eval. 


Neel