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: Unicode errors occur inside of multi-line comments
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 3.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, jftuga, r.david.murray, zach.ware
Priority: normal Keywords:

Created on 2017-01-16 17:06 by jftuga, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
example.py jftuga, 2017-01-16 17:06 multiline comment example
Messages (5)
msg285573 - (view) Author: John Taylor (jftuga) * Date: 2017-01-16 17:06
I am using Python 3.5.2 on OS X 10.11.6.  The same error occurs with 3.5.2 on Windows 10.

When I run the attached code, I get this error:

SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 23-24: truncated \uXXXX escape

I think unicode processing should be ignored inside of multiline comments.
Inside of my comments, I really want to use this text verbatim.
msg285577 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2017-01-16 17:33
Triple-quoted strings are strings, not multi-line comments, though people do abuse them for that purpose sometimes.  Changing this behavior would be a huge change for next to no benefit, so I'm closing the issue.

If you insist on using a triple-quoted string as a comment (which I repeat, it is not; comments are ignored by the compiler, while triple-quoted strings are treated just as any other string literal by the compiler), you can work around this by using a 'raw' string literal:

r"""
dir \\dept.example.com\user
"""
msg285645 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-01-17 14:46
@zach: actually, triple quoted strings *are* suggested as a way to do multiline comments, and are often used for that.  In particular, note that they do not appear in the byte code files if they are not assigned to anything or appear in the docstring position.  This is something I had to prove to myself at one point when I had the same reaction you just did to their use as comments :)  

That said, it is true that they are, first and foremost, strings, so the quoting behavior is not going to change.
msg285658 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2017-01-17 15:29
> they do not appear in the byte code files

It's simple to coonfirm that unassigned string literals get thrown away.:

    >>> code = compile('"doc"\n"unused"\n"us"+"ed"', '', 'exec')
    >>> code.co_consts
    ('doc', 'us', 'ed', None, 'used')
    >>> dis.dis(code)
      1           0 LOAD_CONST               0 ('doc')
                  3 STORE_NAME               0 (__doc__)

      3           6 LOAD_CONST               4 ('used')
                  9 POP_TOP
                 10 LOAD_CONST               3 (None)
                 13 RETURN_VALUE

However, they're retained up to the abstract syntax tree:

    >>> print(ast.dump(ast.parse('"doc"\n"unused"\n"us"+"ed"', '', 'exec')))
    Module(body=[
        Expr(value=Str(s='doc')),
        Expr(value=Str(s='unused')),
        Expr(value=BinOp(left=Str(s='us'),
                         op=Add(),
                         right=Str(s='ed')))])

Sans the doc string behavior, this applies to literals in general. Thus even though the compiler discards these objects, the literal still has to be parsed like any other.
msg285675 - (view) Author: John Taylor (jftuga) * Date: 2017-01-17 18:36
OP here, thanks for replying to this.  I used Zach's suggestion of placing an 'r' in front of triple-quotes.  This accomplishes my goal.
History
Date User Action Args
2022-04-11 14:58:42adminsetgithub: 73471
2017-01-17 18:36:41jftugasetmessages: + msg285675
2017-01-17 15:29:28eryksunsetnosy: + eryksun
messages: + msg285658
2017-01-17 14:46:13r.david.murraysetnosy: + r.david.murray
messages: + msg285645
2017-01-16 17:33:57zach.waresetstatus: open -> closed

nosy: + zach.ware
messages: + msg285577

resolution: not a bug
stage: resolved
2017-01-16 17:06:40jftugacreate