text: 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