[Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes? (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Feb 24 10:09:09 CET 2015

On 24 February 2015 at 18:40, M.-A. Lemburg <mal at egenix.com> wrote:

On 23.02.2015 23:50, Nick Coghlan wrote:

On 24 February 2015 at 08:40, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 24 February 2015 at 07:39, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:

On 23/02/2015 21:27, Serhiy Storchaka wrote:

On 23.02.15 21:58, Joao S. O. Bueno wrote:

That happens all the time, and is this use case that should possibly be addressed here - maybe something as simple as adding a couple of paragraphs to different places in the documentation could mitigate the issue. (in contrast to make a tons of otherwise valid code to become deprecated in a couple releases).

The problem is that the user don't know that he should read the documentation. It just find that his script works with "C:\sample.txt", but doesn't work with "D:\test.txt". He has no ideas what happen. Isn't this why users have help desks? Most don't, and cases like "\n" or "\t" in a Windows path name being converted to whitespace are utterly impossible to look up in an internet search when they fail, so a user learning on their own gets left with a broken program and no particularly effective ways to ask for help figuring it out. I think the easiest way would be to tweak the error message output to indicate the real problem. At the moment, you get: open('c:\test.txt') Traceback (most recent call last): File "", line 1, in FileNotFoundError: [Errno 2] No such file or directory: 'c:\test.txt' which isn't helpful. It would be better to display the escapes as what they are: FileNotFoundError: [Errno 2] No such file or directory: 'c: est.txt' or use a special representation function to highlight the possible problem: FileNotFoundError: [Errno 2] No such file or directory: 'c:[\t]est.txt' - warning: embedded escapes with the representation being: "'c:[\t]est.txt' - warning: embedded escapes" Such a change doesn't require a deprecation phase or a PEP.

Oh, I like that idea, especially the variant that includes a search friendly phrase like "embedded escapes" in the error message. And unlike changing the handling of string literals generally, the impact would be isolated to a few exception repr implementations.

Regards, Nick.

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list