[Python-ideas] Multi-line string indentation

[Joao S. O. Bueno]

/me also would be strongly in favor of this.
"+1 " .

Even taking in consideration the added complexity .

On Fri, 8 Feb 2019 at 13:26, Paul Ferrell <pflarr at gmail.com> wrote:

> 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 at 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 at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>
>
> --
> Paul Ferrell
> pflarr at gmail.com
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190208/97a533e4/attachment.html>