Backticked expressions in triple-quoted strings (a la ABC) would be a
Good Thing, IMO, as it would make the most common cases the easiest to
write & read (most common == results of expressions as evaluated in the
current namespaces, and no special formatting desired).
Dan, I suspect that would meet your most common uses for Lisp-style
backticked expressions. Do you?
Yes. Guido's posting about ABC's backtick was already waiting in my
mailbox when I postemptively sent off my Lisp backquote article.
The idea looks sound (sounds solid?) to me, but I'm not a proper judge.
What are the limits on the expression inside of backticks? Could triple
quotes be embedded inside backticks inside of triple quotes?
If you're writing the HTML text directly to a file, you may be able to
use Perl's "format" and "write" facilities instead.
I hadn't gotten around to figuring out format and write. Thanks.
But my text is not so easily formatted.
> I'd be delighted if I could implement a backquote-like facility in
> Python. I wouldn't expect it to be built-in.
What do you think now? If Guido implements a way (vars/dict/whatever)
to capture the local NS as a dict, we could pass that dict to a
"backtick handling" function, and evaluate the backticked expressions
ourselves via passing the NS dict in turn on to eval. _Seems_ to me
that should work out OK.
OTOH, it sounds like Guido is almost willing to be badgered into doing
it the ABC way.
But can you establish an arbitrary NameSpace while evaluating
the backticked expressions? That is crucial for being able to
generate an expression in a function using the calling function's name
space (or something even more distant) for evaluations.
[...] but then macros have very tricky problems to solve, and I'm
betting you don't need all that hair.
Yes, but most of the problems have to do with providing the right
name space for evaluations, in the macro expansion function, in
the resulting macro expansion, and later. Python should be able get
that problem solved from the outset, given the lessons from the past.
But to really support macros, Python would also need to provide an
accessible representation of parsed expressions, just as Lisp has always
provided, so that macro arguments, or subexpressions of them, could be
any Python code. For efficiency, macro expansion should happen at
compile time too. Macros are great, but it doesn't look like the
current design of Python could be stretched to accommodate them.
Dan LaLiberte
National Center for Supercomputing Applications
liberte@ncsa.uiuc.edu
(Fight interface copyrights and software patents.
**** The current NAFTA will write them in stone !!!! ****
Join the League for Programming Freedom: lpf@uunet.uu.net)