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

[Nick Coghlan]

On 1 Jul 2013 22:39, "Daniel Robinson" <gottagetmac at gmail.com> wrote:
>
> There is another problem with running dedent on docstrings, I believe: a
PEP 257 compliant docstring with a summary line won't dedent at all, since
the first line lacks indentation.
>
> If you wanted to automatically clean docstrings, I think you would want
to use the trim(docstring) function from PEP 257, rather than dedent. But
I'm guessing there was a reason this has not been done before.

I did think of that, and considered the fact existing docstrings would
generally be left alone to be a feature rather than a bug.

Regardless, this is all idle speculation unless/until someone comes up with
a draft patch to add at least dedent, and perhaps indent, as string
methods. It shouldn't be too tricky, but it's still C code.

Cheers,
Nick.

>
> On Mon, Jul 1, 2013 at 5:05 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> http://mail.python.org/mailman/listinfo/python-ideas
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130701/559db4f7/attachment.html>