Re: python strings
Mon, 25 Apr 1994 15:51:15 +0200

If I understand the recent discussions, there's consensus on the need
for something along the lines of triple-quoted strings but not on much

In my private version of what will soon be released as Python, 1.0.2
at the cost of increasingly messy code in tokenizer.c, I've managed to
implement triple-quoted strings, as well as backslash-continued
strings and string literal concatenation as in C, and Donald Beaudry's
%(name)format hack and the vars() function.

I don't think I like the ABC backtick solution so much after all --
problems with it include (but may not be limited to): how to combine
this with format specifiers like %.2f; how to handle nested string
literals inside backticks (the ABC scanner had a stack for this!); and
the fact that backtick already has a meaning outside string literals.

Neither do I like the idea of stripping indentation from strings --
for consistency, this would have to check that all lines in the string
are indented consistently, and it would require adding backslash-space
and backslash-tab as escapes interpreted in string literals. However,
a user function could strip indentation from long string literals
using rather simple regular expression replacement! In the
adventure-game example, such a user function would probably be needed
anyway, in order to reformat the output paragraphs to have a
consistent width.

Here's another half-baked idea: with a little more effort (minimally a
parentheses-counter), %(name)format could be changed into
%(expression)format, passing the expression to eval() with the given
dictionary as globals. Disadvantage: this involves parsing and
compiling the string on each use (unlike back-ticks which would be
recognized by the parser); and it needs a way to pass zero, one or two
dictionaries on to eval(). I'm not sure that the former will be a big
performance hit. The latter could be solved by being a little
cleverer and allowing (), (globals), or (globals, locals) as
right-hand-side argument to the % operator.

--Guido van Rossum, CWI, Amsterdam <>
URL: <>