[Python-ideas] Multi-line string indentation

Mike Miller python-ideas at mgmiller.net
Thu Feb 7 13:13:29 EST 2019

Was: "Dart (Swift) like multi line strings indentation"

This discussion petered-out but I liked the idea, as it alleviates something 
occasionally annoying.

Am supportive of the d'' prefix, perhaps the capital prefixes can be deprecated 
to avoid issues?  If not, a sometimes-optimized (or C-accelerated) str.dedent() 
is acceptable too.

Anyone still interested in this?


On 3/31/18 5:43 PM, Steven D'Aprano wrote:
> 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.

On 4/1/18 4:41 AM, Michel Desmoulin wrote:>
 > A "d" prefix to do textwrap.dedent is something I wished for a long time.
 > It's like the "f" one: we already can do it, be hell is it convenient to
 > have a shortcut.
 > This is especially if, like me, you take a lot of care in the error
 > messages you give to the user. I write a LOT of them, very long, very
 > descriptive, and I have to either import textwrap or play the
 > concatenation game.
 > Having a str.dedent() method would be nice, but the d prefix has the
 > huge advantage to be able to dedent on parsing, and hence be more
 > performant.

More information about the Python-ideas mailing list