Re: python strings
Thu, 21 Apr 1994 09:59:37 +0200 (Consultant) writes:

> This is much better:
> n = 2
> language = 'python'
> """The {n} numbers of {language} objects is usually easy to read in
> long strings because you can see which variable gets substituted in
> a given point."""
> Where inside of a long string, """ TX1 {expr} TX2 """ is equivalant
> to """ TX1 """ + `expr` + """ TX2 """

ABC, Python's predecessor, had a convention whereby a backticks in
string literals did this (sh and Perl also have this in some of their
quoting schemes). In ABC you can write:

WRITE "The `n` numbers of `language` objects is usually easy..."

It might be not too late to include this in Python triple-quoted
strings. On the other hand this doesn't solve the formatting problem
(especially for numbers), and I'd hate to see things like

print """The ` '%03d'%n ` numbers of `language` objects..."""

Also I'd hate to see the difference between Python's different quoting
schemes grow -- it's too late to make ` (or {} for that matter) magic
in standard strings.

When I introduced "..." as alternative string quotes (under much
pressure from certain people -- you know who you are :-) I
deliberately made the semantics identical to those of single quotes --
this was discussed on the mailing list. My preference for
triple-quoted strings would be again that they behave identical to
standard strings EXCEPT for their one redeeming feature (that they can
span lines without the need of backslashes).

For the same reason I don't believe that having some kind of
indentation stripping inside string literals is important enough to
warrant the extra machinery, documentation, confusion etc. If you
insist that your string literals be properly indented, you can still
use literal concatenation.

I DO like Don Beaudry's interpretation of %(<name>)<format> as an
extension of format strings (except I take objection to copying the
key to an array of fixed size :-)

All this needs now would be a built-in function vars() that returns
the locals. This would be a counterpart to dir() and accept a module
as argument as well to return the module's variables. dir() could
then be defined as the (sorted) keys() of the dictionary returned by

How about it, folks?

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