Draft PEP: string interpolation with backquotes

[Roman Suzi]

On Mon, 3 Dec 2001, Christian Tanzer wrote:

> Oren Tirosh <oren-py-l at hishome.net> wrote:
> 
> > > >     The expression may be any valid Python expression not containing
> > > >     the backquote character.
> > > 
> > > This is an unnecessary difference with current backtick expressions.  It's
> > > not particularly pretty to look at, but nested backtick expressions are
> > > unambiguous and work fine.  Artificially restricting them in this context
> > > would be a wart (not to mention that you couldn't reuse the compiler code
> > > that compiles them now).
> > 
> > I am aware of this. The reason for this restriction is simplicity.
> > String interpolation is meant for short expressions, often just a
> > single name. In my proposed implementation most of the processing
> > occurs at the tokenizer while parsing nested backtick expressions
> > unambigously is a job for the parser so this keeps the implementation
> > simple. A possible approach I have considered is to allow nested
> > backticks inside interpolations as long as they are surrounded by at
> > least one level of parens/braces etc. The tokenizer already counts
> > paren levels for expressions extending across newlines.
> 
> Did you consider using the $() notation instead of backticks? bash 2.x
> supports this and it is much easier to read (in particular when
> nested). It also would avoid the overloading of the backticks with two
> completely different meanings.

As I mentioned before, %(...)s or %{...}s notation would be even better
and more Pythonish and more powerful than inline ` ` or innovation with
$-signs.

Sincerely yours, Roman A.Suzi
-- 
 - Petrozavodsk - Karelia - Russia - mailto:rnd at onego.ru -