On 12/02/17 04:53, Steve D'Aprano wrote:
py> s = r'documents\'
File "<stdin>", line 1
s = r'documents\'
^
SyntaxError: EOL while scanning string literal
(I still don't understand why this isn't just treated as a bug in raw string
parsing and fixed...)
I would imagine that it's something to do with the way the parser works
in edge cases such as those below where it struggles to determine how
many string tokens there are (is there a PEP that describes how this
could be easily fixed?)
Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> r'sp\'am' "ha\m"
"sp\\'amha\\m"
>>> r'sp\'am\' "ha\m"
File "<stdin>", line 1
r'sp\'am\' "ha\m"
^
SyntaxError: EOL while scanning string literal
>>> r'sp\'am\' "ha\m'
'sp\\\'am\\\' "ha\\m'
>>>
Actually, while contriving those examples, I noticed that sometimes when
using string literal concatenation, the 'rawness' of the initial string
is sometimes applied to the following string and sometimes not:
>>> "hello \the" r"worl\d"
'hello \theworl\\d'
Makes sense - the initial string is not raw, the concatenated string is.
>>> r"hello \the" "worl\d"
'hello \\theworl\\d'
Slightly surprising. The concatenated string adopts the initial string's
'rawness'.
>>> "hello \the" r"worl\d" "\t"
'hello \theworl\\d\t'
The initial string is not raw, the following string is. The string
following _that_ becomes raw too.
>>> r"hello \the" "worl\d" "\t"
'hello \\theworl\\d\t'
The initial string is raw. The following string adopts that (same as the
second example), but the _next_ string does not!
>>> r"hello \the" "worl\d" r"\t"
'hello \\theworl\\d\\t'
... and this example is the same as before, but makes the third string
"raw" again by explicitly declaring it as such.
Presumably (I haven't checked), this also applies to u-strings and
f-strings - is this a documented and known "wart"/edge-case or is it
something that should be defined and fixed?
E.
--
https://mail.python.org/mailman/listinfo/python-list
