Windows file paths, again
davea at ieee.org
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
> 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 udel.edu> 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.
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"
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