Indented multi-line strings (was: "Data blocks" syntax specification draft)

[Peter J. Holzer]

[Strange: I didn't get this mail through the list, only directly]

On 2018-05-31 14:39:17 +0000, Dan Strohl wrote:
> > This is of course not a problem if the *trailing* quote determines the
> > indentation:
> > 
> >     a_multi_line_string = i'''
> >            Py-
> >           thon
> >         '''
> 
> I get the point, but it feels like it would be a pain to use, and it
> "Feels" different from the other python indenting, which is something
> that I would want to stay away from changing.

Yes, it's the wrong way around. The indentation should be determined by
the start quote. That's why I initially wrote that the quotes must
line up vertically.

Unfortunately you can't write 

    a_multi_line_string = 
        i'''
            Py-
           thon
         '''

although you can write 

    a_multi_line_string = \
        i'''
            Py-
           thon
         '''

which is visually not much worse.

> > > In any case, Chris made a good point that I agree with. This doesn't
> > > really need to be syntax at all, but could just be implemented as a
> > > new string method.
> > 
> > Depending on the details, not quite. A method wouldn't get the horizontal
> > position of the leading quote. It could infer the position of the trailing quote,
> > though.
> > 
> 
> What about if we used Chris's approach, but added a parameter to the
> method to handle the indent? 
> 
> For example, 
> 
> Test = """
>         Hello, this is a
>      Multiline indented
>     String
>     """.outdent(4)

Eek! No, I don't think that's a good idea. It means that the programmer
has to count spaces and has to remember to adjust the parameter if the
indentation changes (e.g. because the block is wrapped in a loop or
factored out to a function).


> The outdent method could look like:
> 
> string.outdent(size=None)
>     """
>     :param size : The number of spaces to remove from the beginning of
>     each line in the string.  Non space characters will not be
>     removed.  IF this is None, the number of characters in the first
>     line of the string will be used.

The default should be the minimum number of leading spaces on non-empty
lines, I think. This is compatible with PEP 257. And in fact it allows
all lines to start with whitespace if the string ends with a newline
(which is a weird dependency, but probably not much of a restriction in
practice).


>     If this is an iterable, the numbers returned from each iteration
>     will be used for their respective lines.  If there are more lines
>     than iterations, the last iteration will be used for subsequent
>     lines.

This looks like overkill to me. What would be the use case?

> This solves the problem in a very pythonic way,

Everybody has their own definition of "pythonic", I guess.

        hp

-- 
   _  | Peter J. Holzer    | we build much bigger, better disasters now
|_|_) |                    | because we have much more sophisticated
| |   | hjp at hjp.at         | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20180531/9f0840c1/attachment.sig>