<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 24, 2015 at 10:00 AM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/24/2015 09:44 AM, Guido van Rossum wrote:<br>
><br>
> TBH I think this will be a tough sell. I worry that an meme will emerge to make all<br>
> string literals use raw mode, or worse, to deprecate non-raw string literals. I'm<br>
> not sure how we'll get out of the whole conundrum, and I'm not in a hurry to see<br>
> this in 3.5.<br>
<br>
</span>So should we move forward with just the better error messages?  It's a good first step, and even if it ends up being the<br>
only step it would be a huge improvement.<br></blockquote></div><br></div><div class="gmail_extra">This is about messages from failing file-open operations if the filename contains an escaped character? I'd go slow there too: here are a lot of places where files are opened and messages are printed, both in the C code and in the stdlib. I'm not sure I buy the argument that just echoing the repr() of the name back doesn't help -- the escapes in there are actually useful in case a filename containing garbage chars (or even a trailing space) was read from some other source.<br><br></div><div class="gmail_extra">And I'd weigh the needs of users who know what they are doing somewhat higher than educating newbies through error messages. While newbies are most likely to try out open() with a string literal, in "real" programs that is rare, and filenames are typically taken from the command line or from some other source where the peculiarities of Python string literals are irrelevant.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>