String handling bug in Python

[David Bolen]

"Delaney, Timothy" <tdelaney at avaya.com> writes:

> import os.path
> 
> path = '//computer/path/to/file'
> path = os.path.normpath(path)
> print path

Um, yeah, but why bother?  I suppose if I were going to present it to
a user but wanted the source to use forward slashes I might do this,
but it's already a Windows specific reference, so I'd probably just go
with backslashes in the code or just leave the forward slashes
unconverted.

Tim's point (I believe) was that in like 99.9% of the cases, you can
just pass the forward slash version of a filename (without any need to
go through the overhead of normalizing it) directly to the Win32 API.
E.g., stick with forward slashes for everything - no difference in
overhead and you avoid the potential to tickle the raw string
limitation.  I do it all the time myself, even in Windows specific
code, since that's the path notation I'm more familiar with.

But if I were in a case where I needed the backslashes, and doing a
hardcoded string like the above, I don't see the benefit to writing it
with a forward slash in the source only to incur runtime overhead to
flip the slashes?  Even if I needed to end in a single backslash ala
this thread :-)

As it turns out, your original "path" would still work fine in most
(maybe all) Win32 filesystem calls.  The problem UNCs tend to be for
(if I recall correctly) stuff like named pipes, and/or things like
service control manager calls or other APIs where one of the
parameters is just a remote machine name (e.g., not a file path) that
needs the \\ prefix.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/