[Python-ideas] Idea for new multi-line triple quote literal

[Nick Coghlan]

On 1 July 2013 11:57, Guido van Rossum <guido at python.org> wrote:

> On Sun, Jun 30, 2013 at 6:47 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> > On 1 July 2013 11:09, Steven D'Aprano <steve at pearwood.info> wrote:
> >> but in either case, I think the choice of --- as delimiter is ugly and
> >> arbitrary, and very likely is ambiguous (currently, x = ---1 is legal
> code).
> >> Similar suggestions to this have been made many times before, you should
> >> search the archives:
> >>
> >> http://mail.python.org/mailman/listinfo/python-ideas
> >
> > I'm still partial to the idea of offering textwrap.indent() and
> > textwrap.dedent() as string methods.
> >
> > 1. You could add a ".dedent()" at the end of a triple quoted string
> > for this kind of problem. For a lot of code, the runtime cost isn't an
> > issue.
> > 2. A JIT would definitely be able to avoid recalculating the result
> every time
> > 3. Even CPython may eventually gain constant folding for that kind of
> > method applied directly to a string literal
> > 4. I dedent and indent long strings more often than I capitalize,
> > center, tab expand, or perform various other operations which already
> > grace the str type as methods.
>
> That's a compelling argument. Let's do it. (Assuming the definition of
> exactly how to indent or dedent is not up for discussion -- if there
> are good reasons to disagree with textwrap now's the time to bring it
> up.)
>

The only slight quirk that occurred to me is that if dedent is a method,
people will probably want to use them with docstrings, and the compiler
currently doesn't allow that.

There are then two options for changing the compiler (if we decide we want
to allow for "neat" docstrings):

1. Implicitly call dedent on docstrings at compilation time (feasible with
dedent as a method).
2. Allow method calls on docstrings without breaking docstring detection

It's technically a separate question from the decision on whether or not to
add the methods, but I figured it was worth bringing up. Touching the
methods of a builtin *and* possibly the compiler behaviour as well is
likely enough to nudge the idea into PEP territory.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130701/ee2f0a96/attachment-0001.html>