Triple-quoted strings hath not the Python-nature

[Lawrence D'Oliveiro]

If triple-quoted strings had the Python-nature, then they would take
indentation into account. Thus:

"""this
is a
multi-line
string."""

would be equivalent to

"this\n is a\n multi-line\nstring."

and not

"this\n is a\n multi-line\n string."

The rule would be: the exact same whitespace characters at the beginning of
the line on which the triple-quoted string starts must also occur at the
start of the lines on which the string continues; these are stripped off
and not included in the string contents. Any additional whitespace is of
course part of the string.

 

[Orestis Markou]

from textwrap import dedent

dedent("""\
this
is a
multi-line
string.""")

will do what you want

 

[Robert Lehmann]

If triple-quoted strings had the Python-nature, then they would take
indentation into account. Thus:

"""this
is a
multi-line
string."""

would be equivalent to

"this\n is a\n multi-line\nstring."

and not

"this\n is a\n multi-line\n string."

The rule would be: the exact same whitespace characters at the beginning
of the line on which the triple-quoted string starts must also occur at
the start of the lines on which the string continues; these are stripped
off and not included in the string contents. Any additional whitespace
is of course part of the string.

"Although practicality beats purity." -- The Zen of Python, by Tim Peters

I would feel greatly offended if I had to indent all *raw* data.

 

[Asun Friere]

That should be "Triple-quoted strings HAVE not the Python-nature."
'Hath' is the archaic 3rd person SINGULAR form of 'to have,' as in "a
tripple-quoted string hath ..."

 

[Steven D'Aprano]

If triple-quoted strings had the Python-nature, then they would take
indentation into account. Thus:

"""this
is a
multi-line
string."""

would be equivalent to

"this\n is a\n multi-line\nstring."

and not

"this\n is a\n multi-line\n string."

I disagree. Triple-quoted strings are exactly the same as other strings:
they capture *exactly* what you put in them, and don't add or subtract
characters which the language designer imagines might be irrelevant for
some people some of the time.

" xyz " gives the exact string " xyz " and not "xyz", no matter how
convenient such behaviour would be for those who want only "xyz". If you
want to strip whitespace from the string, you can strip whitespace from
the string yourself.

Similarly

"""abc
xyz """

results in the exact string you put inside the quotes. Python doesn't try
to guess whether or not the spaces are significant. If you want to strip
whitespace, or any other character, you can do so yourself.

In other words, triple-quoted strings absolutely DO have the Python-
nature, because they refuse to guess what the programmer intends to do
with the string later. If you don't want the spaces, either don't put
them in in the first place, or remove them yourself. Don't expect Python
to guess whether you want the spaces or not.

 

[Lawrence D'Oliveiro]

I disagree. Triple-quoted strings are exactly the same as other strings:
they capture *exactly* what you put in them ...

But that conflicts with the use of whitespace for indentation rules. Other
languages are freeform, and have strings that include whitespace as
significant.

In short, if whitespace is significant outside a string, then it shouldn't
be significant inside. And vice versa.

 

[Lawrence D'Oliveiro]

I would feel greatly offended if I had to indent all *raw* data.

You mean raw strings?

 

[Mel]

But that conflicts with the use of whitespace for indentation rules. Other
languages are freeform, and have strings that include whitespace as
significant.

In short, if whitespace is significant outside a string, then it shouldn't
be significant inside. And vice versa.

I think the rule is that whitespace leading a statement is significant.
Whitespace inside a statement isn't. For example, whitespace inside a pair
of parentheses isn't significant:

Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information..... print (
.... 'a b d c d')
....
a b d c d

 

[Steven D'Aprano]

But that conflicts with the use of whitespace for indentation rules.

No it doesn't. Indentation is a token in Python source code. Strings are
a data type. Syntax rules don't apply to strings because strings are
data, not syntax.

You wouldn't expect the following string literal to raise a syntax error:

"if Time = Money then ..."

Nor does the string "C++", and the string "1/0" doesn't raise
ZeroDivisionError. Strings are data, not syntax. Except for the syntactic
sugar of escape sequences, the contents of strings have no syntax.

(I say content to distinguish it from the delimiters themselves.)

Why should whitespace in string literals be treated as syntactic tokens
when no other characters are?


[...]

In short, if whitespace is significant outside a string, then it
shouldn't be significant inside. And vice versa.

That's an arbitrary rule that makes no sense at all. It's not just
arbitrary, it's *stupid*. Why on earth should the string literal

s = """
text
aligned
to
the
right
"""

raise an IndentationError? Or should it be a SyntaxError?