Playing mind-reader here, best guess is that what Guido had in mind is
that
thing = """...x`expr`y..."""
would be equivalent to
temp = expr
thing = """...x%sy...""" % str(temp)
where expr is any expression legal on the RHS of a single-target
assignment statement.
If so, nesting is implied. However, backticks already have a meaning
outside of strings, so precise rules aren't obvious (least not to me!).
> ...
> I hadn't gotten around to figuring out [Perl's] format and write. ...
> But my text is not so easily formatted.
Nothing more I can say about that without a concrete example, short of
writing a Perl format/write tutorial <wink>. But don't sell 'em short on
the basis of a simplest-possible example! E.g., a powerful "advanced"
technique is to "eval" dynamically-created formats ...
> [back to python]
> ...
> But can you establish an arbitrary NameSpace while evaluating
> the backticked expressions?
I _am_ certain that Guido had just simple uses in mind, like
print """`n` items @ $`price` ea. = $`n * price`"""
Very handy for what it's good for, and clumsy outside that. Still,
Python lets you force arbitrary namespaces on any expression, and
presumably the same mechanisms would work for this too; e.g.,
print eval('"""`n` items @ $`price` ea. = $`n * price`"""',
other_globals, other_locals)
> > 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.
I thought you had a text-formatting problem here, else I wouldn't have
suggested ABC-like backticks as a possible solution! If you're looking
to mimic prefectly-general macros that fiddle, e.g., Python _code_,
string-based anything is a rotten approach. Lisp's macros, and even the
std C preprocessor, are token-based, and know the lexical rules of their
languages inside-out. Building a Python code-fiddler out of ABC-style
backticks would be kinda like writing the Lisp reader in Fortran, except
not as pleasant <0.5 grin>.
> 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.
Well, in a misspent youth, I implemented entire languages out of macros.
The older I get, the less I like them; yet another sublanguage with yet
another set of excruciatingly tricky rules, and _usually_ all in support
of things that "should be" done instead in the base language. E.g., C++
is the clearest recent example that comes to mind of how much a language
can be improved by eliminating perceived needs for macros.
But to each his own. Every now & again, Guido has threatened to make
pieces of Python's parser accessible from Python, and if that's carried
far enough you probably _could_ get a pleasant facility for parsing &
transforming code. Not sure why you'd want to, though <wink>.
if-this-keeps-up-i'm-gonna-ask-for-a-DO-loop-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp