Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011: > -------------------------------------------------- > Proposed new functionality: > -------------------------------------------------- > > * New path module will ONLY support one path sep! There is NO > reason to support more than one. When we support more than one path > sep we help to propagate multiplicity.We should only support the > slash and NOT the backslash across ALL OS's since the slash is more > widely accepted. If an OS does not have the capability to support > only the slash then that OS is not worthy of a Python builtin > module. The users of such OS will be responsible for managing their > OWN os_legacy.path module. We are moving forward. Those who wish to > wallow in the past will be left behind.
People who use windows are used to \ being their pathsep. If you show
them a path that looks like C:/whatever/the/path in an app, they are
going to think you are nuts. It isn't up to us to decide what anyone
uses as a path separator. They use \ natively, so should we. If at
any point Windows as an OS starts using /'s, and not support, actually
uses (in Windows Explorer as default (or whatever the filebrowser's
name is)), it would be great to switch over.
> * Introduce a new method named "partition" which (along with string
> splitting methods) will replace the six methods "basename",
> "dirname", "split", "splitdrive", "splitunc", "splittext". The
> method will return a tuple of the path split into four parts:
> (drive, path, filename, extension). This is the ONLY splitting
> method this module needs. All other splits can use string methods.
I agree, although what if one wants to further split the returned
path, in an OS-independent way? Just because we want all pathseps
to be /, doesn't mean they are (and I personally don't care either
way).
> ~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Too many methods ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Follows is a list of what to keep and what to cull:
>
> + abspath
> + altsep
> - basename --> path.partition[-2]
> + commonprefix
> + curdir
> + defpath
> + devnull
> - dirname --> os.path.join(drive,path)
> + exists
> + expanduser
> + expandvars
> + extsep
> - genericpath --> should be private!
> + getatime
> + getctime
> + getmtime
> + getsize
> + isabs
> + isdir
> + isfile
> + islink
> + ismount
> + join
> - lexists --> duplicate!
> - normcase --> path = path.lower()
Not quite, here are a few implementations of normcase (pulled from 2.7)
# NT
def normcase(s):
"""Normalize case of pathname.
Makes all characters lowercase and all slashes into backslashes."""
return s.replace("/", "\\").lower()
# Mac (Correct in this case)
def normcase(path):
return path.lower()
# POSIX
def normcase(s):
"""Normalize case of pathname. Has no effect under Posix"""
return s
But I can't think of where I would ever use that. Isn't case important on
Windows?
> - normpath --> should not need this!
Why not? It provides an OS-independent way to make the pathname look pretty,
maybe for output? I don't really see a use for it, to be honest. But I'd
rather there be a working solution in the stdlib than have everyone need to
throw in their own that might not handle some things properly. Talk about
multiplicity!
> - os --> should be private!
> + pardir
> + pathsep
> + realpath
> + relpath
> + sep
> - split --> path.rsplit('/', 1)
And on those operating systems where "\\" is the pathsep?
> - splitdrive --> path.split(':', 1)
> - splitunc --> Unix specific!
Err...no. It's for UNC paths, as in \\server\mount\foo\bar. It's not even
in posixpath.py, so in no way could it ever be Unix specific.
> - stat --> should be private!
> + supports_unicode_filenames --> windows specific!
> - sys --> should be private!
> + walk
> - warnings --> should be private!
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 2. Poor Name Choices:
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> * basename --> should be: filename
I agree. The name is a carryover from basename(1) and I guess it's good for
those people, but it certainly isn't the least surprising name. If anything,
I would think the base is everything before!
> * split --> split what?
The path, of course. On its own, it's uninformative, but considering
the whole name is "os.path.split", it's fairly intuitive.
> * splitext --> Wow, informative!
split extension...seems straightforward to me.
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 4. Duplicated functionality.
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> >>> os.path.lexists.__doc__
> 'Test whether a path exists. Returns False for broken symbolic links'
> >>> os.path.exists.__doc__
> 'Test whether a path exists. Returns False for broken symbolic links'
>
> Should have been one method:
> >>> os.path.exists(path, ignoreSymLnks=False)
It is.
/usr/lib64/python2.7/ntpath.py says..
> # alias exists to lexists
>
> lexists = exists
But over here in Not-NT where we actually *have* symlinks to be broken, it's
>>> os.path.lexists.__doc__
'Test whether a path exists. Returns True for broken symbolic links'
>>> os.path.exists.__doc__
'Test whether a path exists. Returns False for broken symbolic links
I agree that it should be an argument to os.path.exists, though.
--
Corey Richardson
"Those who deny freedom to others, deserve it not for themselves"
-- Abraham Lincoln
signature.asc
Description: PGP signature
-- http://mail.python.org/mailman/listinfo/python-list
