Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10546

Re: PyWart: os.path needs immediate attention!

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

PyWart: os.path needs immediate attention! rantingrick <rantingrick@gmail.com> - 2011-07-29 10:22 -0700
  Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 12:53 -0500
    Re: PyWart: os.path needs immediate attention! harrismh777 <harmar@member.fsf.org> - 2011-07-29 14:41 -0500
      Re: PyWart: os.path needs immediate attention! "Waldek M." <wm@localhost.localdomain> - 2011-07-29 21:55 +0200
    Re: PyWart: os.path needs immediate attention! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-30 10:50 +1000
      Function "modes" vs. separate functions (was: PyWart: os.path needs immediate attention!) Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 20:15 -0500
        Re: Function "modes" vs. separate functions Ben Finney <ben+python@benfinney.id.au> - 2011-07-30 11:57 +1000
          Re: Function "modes" vs. separate functions Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 21:28 -0500
      Re: PyWart: os.path needs immediate attention! Terry Reedy <tjreedy@udel.edu> - 2011-07-30 09:48 -0400
      Re: PyWart: os.path needs immediate attention! Robert Kern <robert.kern@gmail.com> - 2011-07-30 23:31 -0400
  Re: PyWart: os.path needs immediate attention! Teemu Likonen <tlikonen@iki.fi> - 2011-07-29 23:07 +0300
    Re: PyWart: os.path needs immediate attention! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-30 10:57 +1000
      Re: PyWart: os.path needs immediate attention! Teemu Likonen <tlikonen@iki.fi> - 2011-08-01 11:19 +0300
        Re: PyWart: os.path needs immediate attention! rantingrick <rantingrick@gmail.com> - 2011-08-02 09:03 -0700
          Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-08-02 17:36 +0100
  Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-07-30 06:25 +1000
  Re: PyWart: os.path needs immediate attention! Corey Richardson <kb1pkl@aim.com> - 2011-07-29 16:44 -0400
  Re: PyWart: os.path needs immediate attention! Alister Ware <alister.ware@ntlworld.com> - 2011-07-29 21:21 +0000
    Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-29 16:36 -0500
  Re: PyWart: os.path needs immediate attention! Chris Angelico <rosuav@gmail.com> - 2011-07-30 07:43 +1000
  Re: PyWart: os.path needs immediate attention! Terry Reedy <tjreedy@udel.edu> - 2011-07-29 19:30 -0400
  Re: PyWart: os.path needs immediate attention! Michael Poeltl <michael.poeltl@univie.ac.at> - 2011-07-30 02:30 +0200
    Re: PyWart: os.path needs immediate attention! Grant Edwards <invalid@invalid.invalid> - 2011-07-30 15:33 +0000
      Re: PyWart: os.path needs immediate attention! Andrew Berg <bahamutzero8825@gmail.com> - 2011-07-30 10:56 -0500
        Re: PyWart: os.path needs immediate attention! alex23 <wuwei23@gmail.com> - 2011-08-02 23:52 -0700
  Re: PyWart: os.path needs immediate attention! Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-07-29 22:17 -0700
  Re: PyWart: os.path needs immediate attention! Gelonida N <gelonida@gmail.com> - 2011-08-03 11:52 +0200

csiph-web