This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Syntax error when using raw strings ending with a backslash.
Type: behavior Stage: resolved
Components: Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: abarry, ned.deily, princemallow
Priority: normal Keywords:

Created on 2016-11-04 16:27 by princemallow, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Capture.PNG princemallow, 2016-11-04 16:27 Image of syntax error
Messages (3)
msg280057 - (view) Author: Mallow (princemallow) Date: 2016-11-04 16:27
I'm not sure if this is a bug or not but I've noticed a behavior that seems incorrect.

The use of raw strings, when used for directory paths ending with a back slash (/) creates a syntax error.

How to reproduce
----------------

Code:

print (r"C:\path\to\a\dir\" + "file.ext")

Result: Syntax Error

Why is this an error, (in my perspective)
-----------------------------------------

One could attempt to be storing the directory information in a variable to write to file that is composed later but would be forced to use a cumbersome normal string having to escape all backslashes.

Example:

outputdir = r"C:\path\to\dir\"
filename = r"file.ext"
writetofile(outputdir + filename)

Argument for why the workaround is not a fix
--------------------------------------------

I believe I read somewhere that python is smart enough to deal with filepaths correctly on linux and windows if you were to switch the slashes. So technically 
outputdir = r"C:/path/to/dir/" 
would work
however this is hard on the workflow since I find it easier to copy and paste paths within windows.

I guess it wouldn't be too unreasonable to do something like:
r"C:\path\to\dir/"
msg280058 - (view) Author: Anilyka Barry (abarry) * (Python triager) Date: 2016-11-04 16:35
That's how strings work, unfortunately. You can't end any string (raw or not) with an odd number of backslashes. You could do the following to get around this limitation:

>>> r"C:\Folder" "\\"
'C:\\Folder\\'

As a side note, please don't upload screenshots if what you're capturing consists only of text (you can paste it directly in your message). This makes it impossible to copy-paste input in the interpreter to try to replicate the issue, and makes it harder/impossible for the blind and visually-impaired to contribute. Thanks!
msg280059 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-11-04 16:43
To expand a bit, the "Python Language Reference" section on "String and Byte Literals" explains:

"Even in a raw literal, quotes can be escaped with a backslash, but the backslash remains in the result; for example, r"\"" is a valid string literal consisting of two characters: a backslash and a double quote; r"\" is not a valid string literal (even a raw string cannot end in an odd number of backslashes). Specifically, a raw literal cannot end in a single backslash (since the backslash would escape the following quote character). Note also that a single backslash followed by a newline is interpreted as those two characters as part of the literal, not as a line continuation."

https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals

Because of the difference between Posix- and Windows-style paths and the potential conflicts in the use of `\` (such as you ran into), Python provides the older os.path and the newer pathlib modules, both of which allow you to deal with path manipulations in a more platform-independent manner.

https://docs.python.org/dev/library/pathlib.html
https://docs.python.org/dev/library/os.path.html
History
Date User Action Args
2022-04-11 14:58:39adminsetgithub: 72797
2016-11-04 16:43:37ned.deilysetnosy: + ned.deily
messages: + msg280059
2016-11-04 16:35:45abarrysetstatus: open -> closed

type: compile error -> behavior

nosy: + abarry
messages: + msg280058
resolution: not a bug
stage: resolved
2016-11-04 16:27:01princemallowcreate