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

Reply via email to