Would you support adding UNC support to os.path on Windows?

[norseman]

Larry Hastings wrote:
> 
> 
> I've written a patch for Python 3.1 that changes os.path so it handles 
> UNC paths on Windows.  You can read about it at the Python bug tracker:
> 
>    http://bugs.python.org/issue5799
> 
> I'd like to gauge community interest in the patch.  After all, it's has 
> been declined before; I submitted a similar patch for 1.5.2 way back in 
> 1999.  (You can read the details of that on the tracker page too.)
> 
> So: would you like to see this patch committed?  Your votes, ladies and 
> gentlemen, if you please.
> 
> For what it's worth, Mark Hammond supports this patch.  (But then, iirc 
> he supported it 1999 too.)
> 
> 
> /larry/
> -- 
> http://mail.python.org/mailman/listinfo/python-list
> 
=========================================================
So we all start from the same page I have cut'n'pasted from the bugs 
posting:
                                -----
---This patch changes "ntpath" so all functions handle UNC paths.

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")

The attached 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 changes "ntpath" ..."    changing or adding to such a 
module which is OS specific is fine with me.

I get a bit concerned of such changes beyond that.  In order to maintain 
ongoing and (hopefully) onward compatibility (eliminating mandatory 
re-writes of perfectly good code) some things need to be avoided.


To reduce the need to maintain multiple versions of source code I use a 
simple technique:

get OS
if OS == this_one
   NearVerb = function of OS-1-specificVerb
elsif  OS == this_other_one
   NearVerb = function of OS-2-specificVerb
.
etc

NearVerb is a slightly modified but still recognizable synonym that is 
then used through out the code.
(windows) import module as zmodule
(linux)   import module as zmodule
you get the idea
If it needs to modify the parameter list (in either direction) - then it 
does so by being made into a translating function.
(windows) import module as wmodule
def zmodule(string):
   fixit code
   wmodule.string
   more fixit code if needed
   return(normal-form-compatible)

Of course the same test can (and is sometimes required to) be applied to 
sections of code because some OS incompatibilities require it.
Mr. Mark Hammond's module. Excellent work, perfect example.

This has worked perfectly across many Operating Systems including but 
not limited to MVS-OS, Windows, MSDOS, UNIX, Linux, PRIME, DEC, Vax-VMS.

I guess that what I'm trying to get across is DO NOT FAVOR a particular 
OS over another. (Unless it's Linux of course. :)   Seriously - a 
programming or scripting or macro language should concentrate on giving 
the SAME code the SAME functionality (errors and all) across all 
architectures and OS protocols on which it is supposed to run.  IF a 
particular OS has something with no twin in others, there is nothing 
wrong with my 'work-around'.

To point it bluntly:  How does one use "F:" in Linux in the identical 
fashion as a MicroSoft OS?  Remember - drive letters for a given 
removable can change throughout the day in MicroSoft.

That the ntpath be a module and aliasable and contain the changes noted 
in your posting would be ideal.  Doing Network Shares under MicroSoft 
seems to be a moving target in the first place.   So:
     "...can ...
         >>> os.chdir("c:foo\\bar")
     but you can't say
         >>> os.chdir("\\\\hostname\\share")
     ..."
should have it's own handlers anyway.

Yes - it would be nice to have the drive letters available for use, but 
not at the expense of the rest of the world.


But Microsoft IS the world?  Bull-shit.

Currently the best time on a particular data reorganization on Windows 
takes 2 hours per 1 year of data.  Best team effort to date.
(Desktop 3+ GHz w/SATA)

My use of Linux takes 8 minutes 41 seconds per 10 years of same data 
doing same re-org.
(Laptop 2.4Ghz w/slow buss/drive speeds)

Programming is not an end unto itself. It's just another tool in the 
box.  If it's broke, messed up or inconsistent - it goes into the trash.
Useless is useless.  Be it program, programming language, programmer.
Be careful of what you break.


Provided conditionals above are met - I vote yes.

Steve
norseman at hughes.net