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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4