On 3/31/2018 10:50 AM, Marius Räsener wrote:
What I have in mind is probably best described with an Example:
print(""" I am a multiline String. """)
the closing quote defines the "margin indentation" - so in this example all lines would get reduces by their leading 4 spaces, resulting in a "clean" and unintended string.
Adding additional default processing to multiline strings is not possible within back-compatibility constraints. It is also not necessary. The current print("I am a\n" "multiline\n" "String.\n") does exactly the same thing as the proposal 2 fewer lines and is more flexible, as one can add an initial \n or an extra \n in the middle or omit the final \n. (For the example, print("I am a\nmultiline\nString\n", also works in 1 line, but does not represent the general case of multiples lone lines.) --- In 3.6, we introduced a new prefix, 'f', so there was no back compatibility issue. There was, however, a combinatorial explosion issue, as 'F' was also added (a mistake, I now think), and no order requirement (possibly another mistake). Hence stringprefix ::= "r" | "u" | "R" | "U" grew to stringprefix ::= "r" | "u" | "R" | "U" | "f" | "F" | "fr" | "Fr" | "fR" | "FR" | "rf" | "rF" | "Rf" | "RF" New unordered 'd' and 'D' prefixes, for 'dedent', applied to multiline strings only, would multiply the number of alternatives by about 5 and would require another rewrite of all code (Python or not) that parses Python code (such as in syntax colorizers). -- Terry Jan Reedy