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
norse...@hughes.net
--
http://mail.python.org/mailman/listinfo/python-list
