Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!eu.feeder.erje.net!bcyclone01.am1.xlned.com!bcyclone01.am1.xlned.com!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <85vbit73jd.fsf@benfinney.id.au>
References: <CAPTjJmqx3s1a0LL4RLgVB1PsOfyF9ryy6nwHwOwrQs1Zx2Hd-Q@mail.gmail.com> <85vbit73jd.fsf@benfinney.id.au>
Date: Mon, 23 Feb 2015 13:55:48 +1100
Subject: Re: Unrecognized backslash escapes in string literals
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.19045.1424660151.18130.python-list@python.org>
Lines: 66
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:86183

On Mon, Feb 23, 2015 at 1:41 PM, Ben Finney <ben+python@benfinney.id.au> wr=
ote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> Why is it that Python interprets them this way, and doesn't even give
>> a warning?
>
> Because the interpretation of those literals is unambiguous and correct.

And it also implies that never, in the entire infinite future of
Python development, will any additional escapes be invented - because
then it'd be ambiguous (in versions up to X, "\s" means "\\s", and
after that, "\s" means something else).

> It's unfortunate that MS Windows inherited the incompatible =E2=80=9Cback=
slash
> is a path separator=E2=80=9D, long after backslash was already establishe=
d in
> many programming languages as the escape character.

I agree, the fault is primarily with Windows. But I've seen similar
issues when people use /-\| for box drawing and framing and such;
Windows paths are by far the most common case of this, but not the
sole.

>> Is there a way to enable such warnings/errors?
>
> A warning or error for a correctly formatted literal with an unambiguous
> meaning would be an up-Pythonic thing to have.
> ...
> This has the advantage that it's the same escape character used for text
> string literals in virtually every other programming language, so you're
> not needing to learn anything unusual.

And yet the treatment of the edge case differs. In C, for instance,
you get a compiler warning, and then the backslash is removed and
you're left with just the other character.

The trouble isn't that people need to learn that backslashes are
special in Python string literals. The trouble is that, especially
when file names are frequently being written with uppercase first
letters, it's very easy to have code that just so happens to work,
without being reliable. Having spent some time working with paths like
these:

fn =3D "C:\Foo\Bar\Asdf.ext"

and then to find that each of these fails, but in a different way:

path =3D "C:\Foo\Bar\"; fn =3D path + "Asdf.ext"
fn =3D "c:\foo\bar\asdf.ext"
fn =3D "c:\users\myname\blah"

would surely count as surprising. Particularly since the last one will
work fine in Python 2 sans unicode_literals, and will then blow up in
Python 3 - because, contrary to the "no additional escapes"
assumption, Unicode strings introduced new escapes, which means that
"\u0123" has different meaning in byte strings and Unicode strings. In
fact, that's an exception to the usual rule of "upper case is safe",
and it's one that *will* trip people up, thanks to the "C:\Users"
directory on a modern Windows system. What's the betting people will
blame the failure on Python 3 and/or Unicode, rather than on the
sloppy use of escapes and the poor choice of path separator on a
popular platform?

ChrisA