I particularly like the str.dedent() idea. Adding yet another string
prefix adds more complexity to the language, which I'm generally not
in favor of.

On 2/7/19, Mike Miller <python-ideas@mgmiller.net> wrote:
> 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?
>
> -Mike
>
>
>
> 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.
>  >
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
Paul Ferrell
pflarr@gmail.com
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/