Proposed: add support for UNC paths to all functions in ntpath
I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows: http://bugs.python.org/issue5799 In a Windows path string, a UNC path functions *exactly* like a drive letter. This patch means that the Python path split/join functions treats them as if they were. For instance: >>> splitdrive("A:\\FOO\\BAR.TXT") ("A:", "\\FOO\\BAR.TXT") With this patch applied: >>> splitdrive("\\\\HOSTNAME\\SHARE\\FOO\\BAR.TXT") ("\\\\HOSTNAME\\SHARE", "\\FOO\\BAR.TXT") This methodology only breaks down in one place: there is no "default directory" for a UNC share point. E.g. you can say >>> os.chdir("c:") or >>> os.chdir("c:foo\\bar") but you can't say >>> os.chdir("\\\\hostname\\share") But this is irrelevant to the patch. Here's what my patch changes: * Modify join, split, splitdrive, and ismount to add explicit support for UNC paths. (The other functions pick up support from these four.) * Simplify isabs and normpath, now that they don't need to be delicate about UNC paths. * Modify existing unit tests and add new ones. * Document the changes to the API. * Deprecate splitunc, with a warning and a documentation remark. This patch adds one subtle change I hadn't expected. If you call split() with a drive letter followed by a trailing slash, it returns the trailing slash as part of the "head" returned. E.g. >>> os.path.split("\\") ("\\", "") >>> os.path.split("A:\\") ("A:\\", "") This is mentioned in the documentation, as follows: Trailing slashes are stripped from head unless it is the root (one or more slashes only). For some reason, when os.path.split was called with a UNC path with only a trailing slash, it stripped the trailing slash: >>> os.path.split("\\\\hostname\\share\\") ("\\\\hostname\\share", "") My patch changes this behavior; you would now see: >>> os.path.split("\\\\hostname\\share\\") ("\\\\hostname\\share\\", "") I think it's an improvement--this is more consistent. Note that this does *not* break the documented requirement that os.path.join(os.path.split(path)) == path; that continues to work fine. In the interests of full disclosure: I submitted a patch providing this exact behavior just over ten years ago. GvR accepted it into Python 1.5.2b2 (marked "*EXPERIMENTAL*") and removed it from 1.5.2c1. You can read GvR's commentary upon removing it; see comments in Misc/HISTORY http://svn.python.org/view/python/trunk/Misc/HISTORY dated "Tue Apr 6 19:38:18 1999". If memory serves correctly, the problems cited were only on Cygwin. At the time Cygwin used "ntpath", and it supported "//a/foo" as an alias for "A:\\FOO". You can see how this would cause Cygwin problems. In the intervening decade, two highly relevant things have happened: * Python no longer uses ntpath for os.path on Cygwin. Instead it uses posixpath. * Cygwin removed the "//a/foo" drive letter hack. In fact, I believe it now support UNC paths. Therefore this patch will have no effect on Cygwin users. What do you think? /larry/
Larry Hastings wrote:
I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows:
+1 for the feature. I have to deal with Windows networks from time to time and this would be useful. Michael
In a Windows path string, a UNC path functions *exactly* like a drive letter. This patch means that the Python path split/join functions treats them as if they were.
For instance:
splitdrive("A:\\FOO\\BAR.TXT") ("A:", "\\FOO\\BAR.TXT")
With this patch applied:
splitdrive("\\\\HOSTNAME\\SHARE\\FOO\\BAR.TXT") ("\\\\HOSTNAME\\SHARE", "\\FOO\\BAR.TXT")
This methodology only breaks down in one place: there is no "default directory" for a UNC share point. E.g. you can say
os.chdir("c:") or os.chdir("c:foo\\bar") but you can't say os.chdir("\\\\hostname\\share") But this is irrelevant to the patch.
Here's what my patch changes: * Modify join, split, splitdrive, and ismount to add explicit support for UNC paths. (The other functions pick up support from these four.) * Simplify isabs and normpath, now that they don't need to be delicate about UNC paths. * Modify existing unit tests and add new ones. * Document the changes to the API. * Deprecate splitunc, with a warning and a documentation remark.
This patch adds one subtle change I hadn't expected. If you call split() with a drive letter followed by a trailing slash, it returns the trailing slash as part of the "head" returned. E.g.
os.path.split("\\") ("\\", "") os.path.split("A:\\") ("A:\\", "") This is mentioned in the documentation, as follows: Trailing slashes are stripped from head unless it is the root (one or more slashes only).
For some reason, when os.path.split was called with a UNC path with only a trailing slash, it stripped the trailing slash:
os.path.split("\\\\hostname\\share\\") ("\\\\hostname\\share", "") My patch changes this behavior; you would now see: os.path.split("\\\\hostname\\share\\") ("\\\\hostname\\share\\", "") I think it's an improvement--this is more consistent. Note that this does *not* break the documented requirement that os.path.join(os.path.split(path)) == path; that continues to work fine.
In the interests of full disclosure: I submitted a patch providing this exact behavior just over ten years ago. GvR accepted it into Python 1.5.2b2 (marked "*EXPERIMENTAL*") and removed it from 1.5.2c1.
You can read GvR's commentary upon removing it; see comments in Misc/HISTORY http://svn.python.org/view/python/trunk/Misc/HISTORY dated "Tue Apr 6 19:38:18 1999". If memory serves correctly, the problems cited were only on Cygwin. At the time Cygwin used "ntpath", and it supported "//a/foo" as an alias for "A:\\FOO". You can see how this would cause Cygwin problems.
In the intervening decade, two highly relevant things have happened: * Python no longer uses ntpath for os.path on Cygwin. Instead it uses posixpath. * Cygwin removed the "//a/foo" drive letter hack. In fact, I believe it now support UNC paths. Therefore this patch will have no effect on Cygwin users.
What do you think?
/larry/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Michael Foord wrote:
Larry Hastings wrote:
I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows:
+1 for the feature. I have to deal with Windows networks from time to time and this would be useful.
+1 from me, too. I haven't looked at the implementation, but for sure the feature would be welcome.
In the interests of full disclosure: I submitted a patch providing this exact behavior just over ten years ago. GvR accepted it into Python 1.5.2b2 (marked "*EXPERIMENTAL*") and removed it from 1.5.2c1.
In the intervening decade, two highly relevant things have happened: * Python no longer uses ntpath for os.path on Cygwin. Instead it uses posixpath. * Cygwin removed the "//a/foo" drive letter hack. In fact, I believe it now support UNC paths. Therefore this patch will have no effect on Cygwin users.
Yes, cygwin supports UNC paths with //host/share, and they use /cygdrive/a, etc., to refer to physical drives. It's been that way for as long as I recall, at least 7 years.
Counting the votes for http://bugs.python.org/issue5799 : +1 from Mark Hammond (via private mail) +1 from Paul Moore (via the tracker) +1 from Tim Golden (in Python-ideas, though what he literally said was "I'm up for it") +1 from Michael Foord +1 from Eric Smith There have been no other votes. Is that enough consensus for it to go in? If so, are there any core developers who could help me get it in before the 3.1 feature freeze? The patch should be in good shape; it has unit tests and updated documentation. /larry/
Larry Hastings wrote:
Counting the votes for http://bugs.python.org/issue5799 :
+1 from Mark Hammond (via private mail) +1 from Paul Moore (via the tracker) +1 from Tim Golden (in Python-ideas, though what he literally said was "I'm up for it") +1 from Michael Foord +1 from Eric Smith
There have been no other votes.
Is that enough consensus for it to go in? If so, are there any core developers who could help me get it in before the 3.1 feature freeze? The patch should be in good shape; it has unit tests and updated documentation.
+1 from me.
Larry Hastings wrote:
Counting the votes for http://bugs.python.org/issue5799 :
+1 from Mark Hammond (via private mail) +1 from Paul Moore (via the tracker) +1 from Tim Golden (in Python-ideas, though what he literally said was "I'm up for it") +1 from Michael Foord +1 from Eric Smith
There have been no other votes.
Is that enough consensus for it to go in? If so, are there any core developers who could help me get it in before the 3.1 feature freeze? The patch should be in good shape; it has unit tests and updated documentation.
I've taken the liberty of explicitly CCing Martin just incase he missed the thread with all the noise regarding PEP383. If there are no objections from Martin or anyone else here, please feel free to assign it to me (and mail if I haven't taken action by the day before the beta freeze...) Cheers, Mark
I've taken the liberty of explicitly CCing Martin just incase he missed the thread with all the noise regarding PEP383.
If there are no objections from Martin
It's fine with me - I just won't have time to look into the details of that change. Regards, Martin
Mark Hammond wrote:
Is that enough consensus for it to go in? If so, are there any core developers who could help me get it in before the 3.1 feature freeze? The patch should be in good shape; it has unit tests and updated documentation.
I've taken the liberty of explicitly CCing Martin just incase he missed the thread with all the noise regarding PEP383.
If there are no objections from Martin or anyone else here, please feel free to assign it to me (and mail if I haven't taken action by the day before the beta freeze...)
Mark: I've reviewed this and it looks okay to me. It passes all the tests on Windows and Linux. But if you could take a look at it before the release tomorrow, I'd appreciate it. I feel good enough about it to check it in if no one else gets to it. Eric.
Eric Smith wrote:
Mark: I've reviewed this and it looks okay to me.
Thanks Eric - I've now applied that patch. As you mentioned in a followup to the bug: | Thanks for looking at this, Mark. If we could only assign issues to | Python 3.2 and 3.3 to change the pending deprecation warning to a real | one, and to remove the function entirely, we'd be all set! I'm always | worried we'll forget these things. (for reference; the patch introduces a PendingDeprecationWarning for ntpath.uncpath) The bug tracker doesn't have these future versions available yet - is there some other way these things should be tracked? I fear simply opening a new bug without a reasonable 'trigger' will linger way beyond the next few versions... Thanks, Mark
participants (6)
-
"Martin v. Löwis" -
Eric Smith -
Larry Hastings -
Mark Hammond -
Michael Foord -
MRAB