Windows file paths, again

Dave Angel davea at
Thu Oct 22 04:35:03 CEST 2009

Dan Guido wrote:
> This doesn't give me quite the results I expected, so I'll have to
> take a closer look at my project as a whole tomorrow. The test cases
> clearly show the need for all the fancy parsing I'm doing on the path
> though.
> Looks like I'll return to this tomorrow and post an update as
> appropriate. Thanks for the help so far!
> --
> Dan Guido
> On Wed, Oct 21, 2009 at 5:34 PM, Terry Reedy <tjreedy at> wrote:
>> Dan Guido wrote:
>>> Hi Diez,
>>> The source of the string literals is ConfigParser, so I can't just
>>> mark them with an 'r'.
>> Python string literals only exist in Python source code. Functions and
>> methods only return *strings*, not literals.  If you mistakenly put the
>> str() representation of a string (such as print gives you) into source code,
>> rather than the repr() output, then you may have trouble.
>> tjr
>> --

For none of your test data does raw() change anything at all.  These 
strings do *not* need escaping.

Now some of the other things you do are interesting:

1) \??\   - presumably you're looking for a "long UNC."  But that's 
signaled by  \\?\    It's used to indicate to some functions that 
filenames over about 260 bytes are permissible.

2) The line:

    if expanded[:8] == "system32" or "syswow64":

doesn't do what you think it does.  it'll always evaluate as true, since 
== has higher priority and "syswow64" is a non-empty string.  If you 
want to compare the string to both, you need to expand it out:

    either  if expanded[:8] == "system32"  or  expanded[:8] == "syswow64"
         or simpler:
     if expanded.startswith("system32") or  expanded.startswith("syswow64"):

3) removing a leading backslash should imply that you replace it with 
the current directory, at least in most contexts.  I'm not sure what's 
the right thing here.


More information about the Python-list mailing list