Multiline strings

[Charles]

You see them all the time in Cobra source code for doc strings, but in fact, they don't exist for expressions. Python has them like so:

Code: Select all

def foo():
    one = """foo foo
bar bar bar"""
    print one
    two = """
        foo foo
bar bar bar
"""
    print two

For Cobra, I'm playing with the idea of requiring that the multiline strings be indented one level. My experience with Python is that my programs can look quite strange when the string contents are flush against the left side, which breaks up the indentation of the code. So that would be:

def foo
    one = """
        foo foo
        bar bar bar"""
    print one
    two = """
        foo foo
        bar bar bar
        """
    print two

I'm also interested in the idea "Multi-line über-raw string literals" at Ideas for Python Enhancements or a variation thereof. Although it's not clear how well that syntax will mesh with popular editors like emacs, vim, TextMate, UltraEdit, etc.

Reactions?

[hopscc]

I like the indented multiline string idea so as to preserve the code indentation.. The downside is that (for text strings )it makes insertion of line leading whitespace a
bit trickier (if indentation sucks up all leading whitespace) or hard to see what whitespace will go into the string and what is ignored ( if suck up whitespace only to next indent level)

the uber-raw addresses both of these - I like the idea here ( a really raw string indented and start delimited) but not the syntax much ( would you use that?)
- how about another string type - blocked-raw string

Code: Select all

 
    x = R'foo foo
        | bar bar
        | no esc sequence expansion(\n) have to do this
        |
        '

[themaniac]

Wouldn't it be more elegant to make it look more like a single line #-prefixed comments, rather than use two different characters??

i.e.

Code: Select all

x = r'My multiline
       'string with formatting
       'That takes notice of newlines and
       '          and allows me to indent
       '

and
y = R'Some other prefix for uber-raw strings\n
       'that don't necessarily linebreak unless there's
       'a newline character\n
       '


Only problem with this (and with the | idea is that it's hard to see the whitespace at the end of the line so in the example above, the string would contain 'there'sa' unless I remembered to put an (otherwise invisible) space at the end of the line

[dennis]

Cobra already uses the underscore for line continuation. Why not use it here with quotes at the beginning and end so that all white space is completely visible? The result is simply an implied string concatenation.

Code: Select all

x = r'My multiline '_
           'string with formatting '_
           'That takes notice of newlines and '_
           '          and allows me to indent '_
           '          AND add white space anywhere ->       '

and
y = R'Some other prefix for uber-raw strings\n'_
           'that don't necessarily linebreak unless there's '_
           'a newline character\n'_
           'NOTE the space at the end of the second line '_
           'and most of these. Presumably this either '_
           'allows long lines to be broken in the source, but '_
           'perhaps not the output, while allowing line wrapping '_
           'at spaces.'


[hopscc]

Using the same char for the block (start)delimiter and the string delimiter looks really confusing (to me at least) and makes parsing complex ( lookahead and pushback)
i.e is the second ' a string terminator or a block delimiter??
Note that for the multiline uberstring all the lines have the code layout nl at the end of them - c'\n' (or any other escape sequence) are not expanded
so

Code: Select all

 R" ... there's
      |a ..."


expands to

Code: Select all

"... there's\na ..."

Using _ and implicit string catenation: all the whitespace isnt visible - there are no nl which there would be if there were really one string carried across
multiple lines (unless you are suggesting implicit string catenation and join with a c'\n')
You can get much the same effect now with some extra punctuation (but you dont get the code layout newlines.

Code: Select all

   x = r'My multiline ' +_
         r'string with formatting ' + _
         r'That takes notice of newlines and'+_
         r'          and allows me to indent '+ _
         r'          AND add white space anywhere ->       '


howsthis - allow an optional trailing delimiter before the \n on each line also ( delimiters in the line are ignored)
allowing any trailing spaces to be made visible

Code: Select all

   x = R'My multiline
         |string with formatting |
         |That takes notice of newlines and |
         |          and allows me to indent
         |          AND add white space anywhere ->       |
                        |'
 

The processing on an uber string is only to remove the leading indentation (if not done already) ,
remove the leading block delimiter and remove any trailing delimiter thats before a \n or end of string

[hopscc]

Pox I screwed up the last code example
should be

Code: Select all

       x = R'My multiline
             |string with formatting |
             |That takes notice of newlines and |
             |          and allows me to indent
             |          AND add trailing white space  ->       |
             |
             ' 


equivalent to

Code: Select all

       x = "My multiline\nstring with formatting \nThat takes notice of newlines and \n          and allows me to indent\n          AND add white space anywhere ->       \n\n"
 

sans the line wrap.

[dennis]

unless you are suggesting implicit string catenation and join with a c'\n'

Yes. And then if you want no added c'\n', you'd use the explicit concatenation:

Code: Select all

x = r'This is a string with line breaks in ' +_
            r'the source for readability, but not in the result.'

Another idea: Why can't newlines follow the model of the string modifier (e.g. "r") and look like this?:

Code: Select all

x = r'This string is terminated by a newline.'n
y = r'This string is equivalent.\n'
z = r'This is a multiline string with implied concatenation and '_
            'implied newlines allowing white space '_
            '     wherever needed     '
s = r'This string is explicitly concatenated and 'n+_
            r'requires that newlines are also explicit where desired.'n

But having it both ways could be confusing.

[chris]

Isn't the doc string meant to replace all this punctuation-loaded string concatenation? And regarding correct indentation, I don't see a problem with taking indentation of the first doc string line as reference and ignoring this amount of indentation on the following lines of the same doc string, e.g.:

Code: Select all

def myfunct
    doc = """
        blah blah blah
            blah blah
        blah blah
        """


For me it is clear to see which indentation is part of the doc string, and if you really write pages of documentation with sophisticated indentation you could still fall back to using single line strings with line continuation chars.
I do like the idea of aligning doc strings at the current indentation level. IIRC Boo does it this way.

This adds much to readability, and after all, the place where doc strings are viewed most is in the source code itself.

Just my twopence.

Chris

[dennis]

<snip>
I don't see a problem with taking indentation of the first doc string line as reference and ignoring this amount of indentation on the following lines of the same doc string
<snip>

How would you include some white space at the beginning of the first line of the string? BTW, I don't think we're talking about doc strings.

[chris]

How would you include some white space at the beginning of the first line of the string?

I see your point - as long as indentation rules do not require a strict amount of spaces per indentation level, there is no way to determine where code indentation ends and string indentation begins. However, in such a situation the fallback to concatenated single-line strings is always an option.

BTW, I don't think we're talking about doc strings.

You're right, my last sentence missed the point.