[issue5799] Change ntpath functions to implicitly support UNC paths

Eric Smith added the comment: 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. -- _

[issue5799] Change ntpath functions to implicitly support UNC paths

Mark Hammond added the comment: Checked into the trunk as r72387 (after normalizing whitespace in ntpath.py after the precommit-hook failed). Thanks Larry and Eric! -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: I tested your patch and it looks good to me. I didn't get the deprecation warning on ntpath.splitunc unless I disabled all warnings. -- ___ Python tracker

[issue5799] Change ntpath functions to implicitly support UNC paths

Mark Hammond added the comment: This looks good to me. My take on Guido's earlier notes are that they caused a problem in practice, and the philosophical concerns added justification for removing it. I'm yet to meet a Windows user with a philosophical objection to this. I'm attaching a new pa

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: I don't know what would be proper, but I'm happy to change it if you think that's best. -- ___ Python tracker ___ __

[issue5799] Change ntpath functions to implicitly support UNC paths

Mark Hammond added the comment: Should the DeprecationWarning for splitunc be a PendingDeprectionWarning for 3.1 and get 'upgraded' in 3.2? -- ___ Python tracker ___

[issue5799] Change ntpath functions to implicitly support UNC paths

Changes by Eric Smith : -- assignee: eric.smith -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: I've never understood what is the "philosophical problem" per se. It's clear from his implementation--Guido created "splitunc" when he removed my patch--that he thinks these should be precise string operations. Whereas I propose making these slightly higher-le

[issue5799] Change ntpath functions to implicitly support UNC paths

Eric Smith added the comment: Looking at Guido's removal of this back in 1999, he says: """ * Lib/ntpath.py: Withdraw the UNC support from splitdrive(). Instead, a new function splitunc() parses UNC paths. The contributor of the UNC parsing in splitdrive() doesn't like it, but I haven't heard

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: Just 'cause I like you, here's an updated patch. The only change is the removal of "import itertools" and the update of the base version. -- Added file: http://bugs.python.org/file13896/lch.ntpath.r72345.diff ___ Py

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: Whoops, yeah, that was me forgetting that in py3k itertools.izip became just "zip". I'll remove it in my branch in case I generate another patch. -- ___ Python tracker ___

[issue5799] Change ntpath functions to implicitly support UNC paths

Eric Smith added the comment: This looks okay to me. (The itertools import isn't needed, but easy enough to fix on checkin.) I'd still like someone else to look it over, but if no one does before the beta, I'll check it in. -- keywords: +needs review stage: -> patch review __

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: I stared at it some more. Now I understand what "for ... : else:" was for in the original. The "else: i += 1" ensures that if the "for" loop runs to completion "i" is set to the length of the shorter of the two lists. Anyway, my reimplemented loop accomplishe

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: Sorry for the quick double-patch, but I realized that there was no test for the obverse case, where "path" is / and "curdir" is non-empty. So I threw in some more tests. -- Added file: http://bugs.python.org/file13891/lch.ntpath.r72309.diff.2

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: As promised, a fresh patch. Note that the current formulation of that troublesome loop in relpath() is *very* much on purpose. The removal of the "else" is no longer a bug :) -- Added file: http://bugs.python.org/file13890/lch.ntpath.r72309.diff

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: Sweet jumping rhubarb! I didn't know about this "for ...: else:" construct in Python. When I was editing it I thought it was my editor stumbling over a tab, and the "else" went with the "if" *inside* the "for". You're absolutely right that the current code is

[issue5799] Change ntpath functions to implicitly support UNC paths

Eric Smith added the comment: > I've generated a new patch, attached. I don't know why you had trouble > applying. Yeah, I'm not sure what that was about. Part of the patch applied, but not the rest. In any event, the current one applied cleanly. I'm not sure this part of the patch is correct

[issue5799] Change ntpath functions to implicitly support UNC paths

Larry Hastings added the comment: I've generated a new patch, attached. I don't know why you had trouble applying. I tested this one with a clean tree and "patch -p1 < ..." and it applied cleanly. If it fails again, how about I upload the three modified files? I removed the extraneous change

[issue5799] Change ntpath functions to implicitly support UNC paths

Eric Smith added the comment: The doc patch doesn't apply cleanly for me. There are a number of code cleanups in the patch, like 0->False, 1->True, the improvement of the params to path(), improvement in isabs(), etc. I think these cleanups should be made in a separate patch, so that it's easie

[issue5799] Change ntpath functions to implicitly support UNC paths

Amaury Forgeot d'Arc added the comment: I confirm that the cygwin port uses posixpath, and that the current patch has no impact there, except for users which explicitly import ntpath to get nt semantics. -- nosy: +amaury.forgeotdarc ___ Python tracke

[issue5799] Change ntpath functions to implicitly support UNC paths

Paul Moore added the comment: This sounds reasonable to me. I would like to see this patch applied. Note - someone involved with the cygwin port should confirm that the patch does indeed no longer cause issues for cygwin. -- nosy: +pmoore ___ Python

[issue5799] Change ntpath functions to implicitly support UNC paths

New submission from Larry Hastings : 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: >>> splitd