On 8/9/2019 3:56 PM, Steven D'Aprano wrote:
I'm not trying to be confrontational, I'm trying to understand your 
use-case(s) and see if it would be broken by the planned change to 
string escapes.

Yeah, that's fine. Sometimes it is hard to communicate via email (versus saying a lot).


On Fri, Aug 09, 2019 at 03:18:29PM -0700, Glenn Linderman wrote:

On 8/9/2019 2:53 PM, Steven D'Aprano wrote:

On Fri, Aug 09, 2019 at 01:12:59PM -0700, Glenn Linderman wrote:


The reason I never use raw strings is in the documentation, it is
because \ still has a special meaning, and the first several times I
felt the need for raw strings, it was for directory names that wanted to
end with \ and couldn't.

Can you elaborate? I find it unlikely that I would ever want a docstring

I didn't mention docstring.  I just wanted a string with a path name 
ending in \.

You said you never used raw strings in the documentation. I read that as 
doc strings. What sort of documentation are you writing that isn't a doc 
string but is inside your .py files where the difference between raw and 
regular strings is meaningful?

No, what I said was that the reason is in the documentation. The reason that I don't use raw strings is in the Python documentation. I don't claim to use raw strings for documentation I write. The reason is because \" to end the string doesn't work, and the first good-sounding justification for using raw strings that I stumbled across was to avoid "c:\\directory\\" in favor of   r"c:\directory\"  but that doesn't work, and neither do r"c:\directory\\". Since then, I have not found any other compelling need for raw strings that overcome that deficiency... the benefit of raw strings is that you don't have to double the \\. But the benefit is contradicted by not being able to use one at the end of sting. If you can't use it at the end of the string, the utility of not doubling them in the middle of the string is just too confusing to make it worth figuring out the workarounds when you have a string full of \ that happens to end in \. Just easier to remember the "always double \" rule, than to remember the extra "but if your string containing \ doesn't have one at the end you can get away with using a raw string and not doubling the \.


      

        
Windows users are used to seeing backslashes in paths, I don't care to 
be the one to explain why my program uses / and all the rest use \.


      

      
If you don't use raw strings for paths, you get to explain why your 
program uses \\ and all the rest use \ *wink*

    

    Wrong. Users don't look at the source code. They look at the output.
    I also don't want to have to write code to convert /-laden paths to
    \-laden paths when I display them to the user.

    

    

      

If they're Windows end users, they won't be reading your source code and 
will never know how you represent hard-coded paths in the source code.

    

    

    They will if I display the path as a default value for an argument,
    or show them the path for other reasons, or if the path shows up in
    an exception message.

    

    

      

If they're Windows developers, they ought to be aware that the Windows 
file system API allows / anywhere you can use \ and it is the 
common convention in Python to use forward slashes.

    

    

    This, we can agree on.

    

    

      
I'm also curious why the string needs to *end* with a backslash. Both of 
these are the same path:

    C:\foo\bar\baz\
    C:\foo\bar\baz


    

    

    Sure. But only one of them can be used successfully with   +
    filename  (for example).