Pre-PEP: d-string / Dedented Multiline Strings with Optional Language Hinting

[Lucas_Malor]

@jsbueno

I don’t see anyone against just doing the plain transform.

I’m not against, but I consider the d-string superior, for a simple reason: IMO Python should have that by default. And there’s more.

My idea is not a new idea. I discovered this post:

D-string vs str.dedent()

I previously created a thread about str.dedent(). Before writing a PEP for it, I would like to consider adding a prefix of d/D to string literals (d-string). This is rough idea about d-string: d-string starts with triple quote (""" or ''') followed by newline. The newline is not included in the string. d"spam" and d'''egg''' are syntax error. d-string ends with indent and triple quote. Only the indent to be removed is allowed before closing triple quote in the line. Indents in lines that …

I quote some posts, that add really strong points:

@storchaka

With d-strings you can write the following:

def f():
    return d"""First shalt thou take out the Holy Pin.
        Then shalt thou count to three, no more, no less.
        Three shall be the number thou shalt count, and the number of the \
        counting shall be three.
        Four shalt thou not count, neither count thou two, excepting that \
        thou then proceed to three.
        Five is right out!
        Once the number three, being the third number, be reached, then \
        lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, \
        who, being naughty in My sight, shall snuff it."""

Sentences are separated by newlines, long sentences are split on several physical lines on 80 columns in the source code, and these lines are nicely indented, but the resulting string do not contain newlines or extra spaces in the middle of sentence. It is not possible to do this with str.dedent().

@guido

I see. Very cool. And now I agree that requiring an API for the same thing is problematic.

Really cool indeed. I love it.

@methane

The advantages of d-string over str.dedent are as follows:

• It has slightly less visual noise than .dedent(). It will be nice to be used with multiline string in function arguments. (sample)
• It can be combined with f-strings. The indentation can be statically calculated and removed at compile time before evaluating the f-string.
• The string can start with d""" instead of """\. The compiler will remove the first newline, which can reduce visual noise.
  • d-strings might make triple quotes and the first newline mandatory.
• It is possible to specify the amount of indentation to remove on the final line of the string.
  • This idea is ported from Swift. See Documentation

Don’t know if it’s a good idea to dedent before f-strings are applied. What if the f-string adds newlines and indentations?

For the rest, I completely agree.

@storchaka

Python was one of first programming languages that added support of triple-quoted string literals. Since then, the support of them has been added in many other programming languages, both new (like Julia) and old (like Java). Where they were added later, usage patterns and issues were taken into account. It would be good if Python borrowed this experience.

This is exactly my main point. Having to write d""" will be boring, since the best was it did it by default. But the ship is sailed.

On the contrary, having to write:

"""
    hello
    my
    friend
""".dedent()

it’s not only more boring, but absolutely less powerful, per before quotes.

At this point, instead of having yet-another-method similar to textwrap.dedent(), I prefer to have nothing. We can instead improve textwrap.dedent() with an optional kwarg.

Just my 0.0.1 cents.