On Tue, Feb 24, 2015 at 1:00 PM, Joao S. O. Bueno <jsbueno at python.org.br> wrote: > On 23 February 2015 at 18:39, Greg Ewing <greg.ewing at 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 "\<x>" 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 at 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 at 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 at python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150224/bfc1ec7d/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4