PyWart: os.path needs immediate attention!

[Corey Richardson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20110729/ac19a1b2/attachment-0001.sig>