Larry Hastings la...@hastings.org 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 rep...@bugs.python.org
Mark Hammond mhamm...@users.sourceforge.net 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
___
Eric Smith e...@trueblade.com 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.
Eric Smith e...@trueblade.com 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
Larry Hastings la...@hastings.org 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 rep...@bugs.python.org
Larry Hastings la...@hastings.org 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
Eric Smith e...@trueblade.com 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
Larry Hastings la...@hastings.org 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
Changes by Eric Smith e...@trueblade.com:
--
assignee: eric.smith -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5799
___
___
Python-bugs-list
Mark Hammond mhamm...@users.sourceforge.net added the comment:
Should the DeprecationWarning for splitunc be a PendingDeprectionWarning
for 3.1 and get 'upgraded' in 3.2?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5799
Larry Hastings la...@hastings.org 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 rep...@bugs.python.org
http://bugs.python.org/issue5799
Mark Hammond mhamm...@users.sourceforge.net 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
Eric Smith e...@trueblade.com 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
Larry Hastings la...@hastings.org 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
Larry Hastings la...@hastings.org 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:
Larry Hastings la...@hastings.org 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:
Larry Hastings la...@hastings.org 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
Larry Hastings la...@hastings.org 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
Eric Smith e...@trueblade.com 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,
Paul Moore p.f.mo...@gmail.com 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
Amaury Forgeot d'Arc amaur...@gmail.com 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
New submission from Larry Hastings la...@hastings.org:
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
22 matches
Mail list logo
