(original) (raw)



On Tue, Feb 24, 2015 at 1:00 PM, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
On 23 February 2015 at 18:39, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
\> Serhiy Storchaka wrote:
\>>
\>> 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.
\>
\>
\> Even with the syntax error, there are filenames that
\> will mysteriously fail, e.g. "C:\\ninjamoves.txt".


That is the reason I urge folks to think about the root cause,
and check if this proposal is the best way to tackle it:
The failing cases are the ones that won't be affected by this change at all -
as they are valid escaped strings!

I would argue that some cases working is the root cause of the confusion. If \*none\* of the cases work, it would be a lot less confusing, even if the error message is different. Trying to make the error messages more similar, or more identifying, may be a good idea (as long as they aren't misleading when people \*meant\* to use escape sequences in a string) but fortunately that's separate from making the cases that current silently and misleadingly work, emit a warning (or error.)

Emitting a warning does not address the question 'why does "C:\\test" not exist when I see it in Explorer.' It does address the question 'why does my program break when I change "C:\\Test" to "C:\\test". It also addresses 'why does my regexp not work when I change "\\d+" to "\\b\\d+", and unlike changing the error message for opening files it is much closer, in time and space, to the actual problem. It's a helpful thing regardless of what other changes are made.

I do expect there to need to be a much longer deprecation period than one or even two releases, though: there is a lot of code that uses the misfeature, mostly by accident (not realizing they should be using r'', etc.)

There will be no error for
c:\\tmp\\myfile.txt - it will ever be just "file not found" - unless the
warning comes to
using "\\" as file path separator (and no, I don think just doing that
would properly
address the issue as well).

Could we just use Guido's time machine and go back to the point in time where
some MS head decided to go with "\\" instead of "/", and deliver a well
placed punch? :-)

Or maybe have IOError for "file not found" to get some fuzzy logic and
display a more verbose error message if there are "\\n"s and "\\t"s on
the filename
and platform is Windows? I think that could go along the proposal for
deprecating non-escaping "\\" sequences .

By the way, although I am writing to get the root issue covered, I think
deprecating them would be a good thing, yes. Despite my previous comment
on deprecating code that works, on a deeper though it \_is\_ worth the issue.

js
\-><-



\>
\> --
\> Greg
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/thomas%40python.org



--
Thomas Wouters <thomas@python.org>

Hi! I'm an email virus! Think twice before sending your email to help me spread!