Georg Brandl wrote:
FWIW, I'm -1 on both proposals too. I like implicit string literal concatenation and I really can't see what we gain from backslash continuation removal.
Georg
-1 on removing them also. I find they are helpful. It could be made optional in block headers that end with a ':'. It's optional, (just more white space), in parenthesized expressions, tuples, lists, and dictionary literals already.
[1,\ ... 2,\ ... 3] [1, 2, 3]
(1,\ ... 2,\ ... 3) (1, 2, 3)
{1:'a',\ ... 2:'b',\ ... 3:'c'} {1: 'a', 2: 'b', 3: 'c'}
The rule would be any keyword that starts a block, (class, def, if, elif, with, ... etc.), until an unused (for anything else) colon, would always evaluate to be a single line weather or not it has parentheses or line continuations in it. These can never be multi-line statements as far as I know. The back slash would still be needed in console input. The following inconsistency still bothers me, but I suppose it's an edge case that doesn't cause problems.
print r"hello world\" File "<stdin>", line 1 print r"hello world\" ^ SyntaxError: EOL while scanning single-quoted string print r"hello\ ... world" hello\ world
In the first case, it's treated as a continuation character even though it's not at the end of a physical line. So it gives an error. In the second case, its accepted as a continuation character, *and* a '\' character at the same time. (?) Cheers, Ron