[Python-ideas] Dart like multi line strings identation

[Steven D'Aprano]

On Sat, Mar 31, 2018 at 04:50:03PM +0200, Marius Räsener wrote:

[...]
> What I have in mind is probably best described with an Example:
> 
> print("""
>     I am a
>     multiline
>     String.
>     """)
> 
> the closing quote defines the "margin indentation" - so in this example all
> lines would get reduces by their leading 4 spaces, resulting in a "clean"
> and unintended string.

Backwards compatibility rules this out. I have many strings that 
intentionally include indents and you will annoy me no end if you 
make those indents disappear :-)

But having said that, for every one of those, I have a lot more where 
the indents are annoying. I either outdent the lines:

def spam():
    text = """some text
another line
and a third one
"""
    print(text)


or I use implicit string concatenation:

def spam():
    text = ("some text\n"
            "another line\n"
            "and a third\n")
    print(text)


neither of which I'm really happy with.

The ideal solution would:

- require only a single pair of starting/ending string delimiters;

- allow string literals to be indented to the current block, for 
  the visual look and to make it more convenient with editors
  which automatically indent;

- evaluate without the indents;

- with no runtime cost.


One solution is to add yet another string prefix, let's say d for 
dedent, but as Terry and others point out, that leads to a combinational 
explosion with f-strings and r-strings already existing.

Another possibility is to make dedent a string method:

def spam():
    text = """\
           some text
           another line
           and a third
           """.dedent()
    print(text)

and avoid the import of textwrap. However, that also imposes a runtime 
cost, which could be expensive if you are careless:

for x in seq:
   for y in another_seq:
      process("""/
              some large indented string
              """.dedent()
              )

(Note: the same applies to using textwrap.dedent.)

But we could avoid that runtime cost if the keyhole optimizer performed 
the dedent at compile time:

    triple-quoted string literal
    .dedent()

could be optimized at compile-time, like other constant-folding.

Out of all the options, including the status quo, the one I dislike the 
least is the last one:

- make dedent a string method;

- recommend (but don't require) that implementations perform the 
  dedent of string literals at compile time;

  (failure to do so is a quality of implementation issue, not a bug)

- textwrap.dedent then becomes a thin wrapper around the string method.


Thoughts?





-- 
Steve