PyWart: os.path needs immediate attention!

Discussion in 'Python' started by rantingrick, Jul 29, 2011.

  1. rantingrick

    rantingrick Guest

    --------------------------------------------------
    Overview of Problems:
    --------------------------------------------------

    * Too many methods exported.
    * Poor choice of method names.
    * Non public classes/methods exported!
    * Duplicated functionality.

    --------------------------------------------------
    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.

    * 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.

    --------------------------------------------------
    Expose of the Warts of current module:
    --------------------------------------------------


    ~~~~~~~~~~~~~~~~~~~~~~~~~
    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()
    - normpath --> should not need this!
    - os --> should be private!
    + pardir
    + pathsep
    + realpath
    + relpath
    + sep
    - split --> path.rsplit('/', 1)
    - splitdrive --> path.split(':', 1)
    - splitext --> path.rsplit('.')
    - splitunc --> 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
    * split --> split what?
    * splitext --> Wow, informative!

    ~~~~~~~~~~~~~~~~~~~~~~~~~
    3. Non Public Names Exposed!
    ~~~~~~~~~~~~~~~~~~~~~~~~~

    * genericpath
    * os
    * stat
    * sys
    * warnings


    Note: i did not check the Unix version of os.path for this.

    ~~~~~~~~~~~~~~~~~~~~~~~~~
    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)
     
    rantingrick, Jul 29, 2011
    #1
    1. Advertising

  2. rantingrick

    Andrew Berg Guest

    On 2011.07.29 12:22 PM, rantingrick wrote:
    > * 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.

    So now you propose that not only does Python need drastic changes, but a
    major operating system family as well (I know Windows will accept a
    forward slash in some contexts, but I'd be pretty surprised if one could
    completely replace the backslash with it completely)? Interesting.

    > * 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.

    So these pretty specifically named functions (except perhaps split)
    should be replaced with one ambiguously named one? Interesting.

    > - dirname --> os.path.join(drive,path)

    Now you've stopped making sense completely. Also interesting.

    > * split --> split what?
    > ...
    >>>> os.path.exists(path, ignoreSymLnks=False)

    I actually agree with you on these, which I suppose is interesting.

    --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
     
    Andrew Berg, Jul 29, 2011
    #2
    1. Advertising

  3. rantingrick

    harrismh777 Guest

    Andrew Berg wrote:
    > * 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.


    I actually agree with this. Like Timon once told Pumbaa, "Ya gotta put
    your behind in the past. . . "

    The backslash sep is an asinine CPM/80 | DOS disk based carry-over which
    does not fit well with the modern forward direction. The disk based file
    system carry-over is bad enough; but, propagating multiple ways of doing
    simple things like specifying file-system paths is not helpful in any
    context.

    The modern direction today (almost universally on the server-side) is to
    specify the path from the root "/" regardless of physical disk array
    geometries (or physical drives "C:\"). The forward slash actually makes
    some philosophical sense, and of course is more aesthetically pleasing.

    So, let's put our behinds in the past and slash forward !





    --
    m harris

    FSF ...free as in freedom/
    http://webpages.charter.net/harrismh777/gnulinux/gnulinux.htm
     
    harrismh777, Jul 29, 2011
    #3
  4. rantingrick

    Waldek M. Guest

    Dnia Fri, 29 Jul 2011 14:41:22 -0500, harrismh777 napisa³(a):
    > The backslash sep is an asinine CPM/80 | DOS disk based carry-over which
    > does not fit well with the modern forward direction. The disk based file
    > system carry-over is bad enough; but, propagating multiple ways of doing
    > simple things like specifying file-system paths is not helpful in any
    > context.


    Please, do tell it to Microsoft. And once you've convinced them,
    and they've implemented it, do report :)

    Waldek
     
    Waldek M., Jul 29, 2011
    #4
  5. * 2011-07-29T10:22:04-07:00 * <> wrote:

    > * New path module will ONLY support one path sep! There is NO reason
    > to support more than one.


    Pathnames and the separator for pathname components should be abstracted
    away, to a pathname object. This pathname object could have a "path" or
    "directory" slot which is a list of directory components (strings). Then
    there would be method like "to_namestring" which converts a pathname
    object to native pathname string. It takes care of any platform-specific
    stuff like pathname component separators. Of course "to_pathname" method
    is needed too. It converts system's native pathname string to a pathname
    object.
     
    Teemu Likonen, Jul 29, 2011
    #5
  6. On Sat, Jul 30, 2011 at 3:22 AM, rantingrick <> wrote:
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    >  3. Non Public Names Exposed!
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    >  * genericpath
    >  * os
    >  * stat
    >  * sys
    >  * warnings
    >


    And you intend to do what, exactly, with these?

    > - splitunc --> Unix specific!


    1) So?
    2) http://docs.python.org/library/os.path.html#os.path.splitunc says
    "Availability: Windows."

    If you actually meant "Windows specific" then the first one still holds.

    Under Unix, the only place UNC names are supported is CIFS mounting
    (and equivalents, smbmount etc).

    ChrisA
     
    Chris Angelico, Jul 29, 2011
    #6
  7. 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

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v2.0.17 (GNU/Linux)

    iQEcBAEBCAAGBQJOMxucAAoJEAFAbo/KNFvpM7QIAICiWYI6Y/Ipr4jyF1YgsYhN
    m/9BpYjqU9F/isiiRSGrnitpFWrjG2FoKc9w71/4JExHg1XIhrUJI0kg4LeofTOE
    Qm2pWEzxNZkMVdC3c3BzInYhRoxof2UZhp1gDkRpw1cJcm/6vm9mGarqd3kBxa90
    +edqSUDvQV7MPydn99gI0Kw2gE+OFi6363UlsRCJZSh8gu2mFn0uBKRQGXwOdUc5
    VOjgCUcoHuu/qfK5TP479KGiJQWh1//5P+iLPnKdapIeBs79Tog8yV5S47fdPe5e
    3k4VC9jEF7KVGhB1L1V7EDQg7bojYDTcT1+H8kFFlSvK1YHLJdozh5MbBnwSVg4=
    =o+aC
    -----END PGP SIGNATURE-----
     
    Corey Richardson, Jul 29, 2011
    #7
  8. rantingrick

    Alister Ware Guest

    On Fri, 29 Jul 2011 10:22:04 -0700, rantingrick wrote:

    > --------------------------------------------------
    > Overview of Problems:
    > --------------------------------------------------
    >
    > * Too many methods exported.
    > * Poor choice of method names.
    > * Non public classes/methods exported!
    > * Duplicated functionality.
    >
    > --------------------------------------------------
    > 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.
    >
    > * 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.
    >
    > --------------------------------------------------
    > Expose of the Warts of current module:
    > --------------------------------------------------
    >
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 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()
    > - normpath --> should not need this!
    > - os --> should be private!
    > + pardir + pathsep + realpath + relpath + sep - split -->
    > path.rsplit('/', 1)
    > - splitdrive --> path.split(':', 1)
    > - splitext --> path.rsplit('.')
    > - splitunc --> 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 * split --> split what?
    > * splitext --> Wow, informative!
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 3. Non Public Names Exposed!
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    > * genericpath * os * stat * sys * warnings
    >
    >
    > Note: i did not check the Unix version of os.path for this.
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 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)


    so far all I have is posts stating that everything is wrong.

    instead of all this negativity why don't you try being productive for a
    change either make a suggestion for an addition (ie something that does
    not yest exits) or better yet give us all the benefit of your supreme
    coding talent & provide some code?



    --
    One expresses well the love he does not feel.
    -- J.A. Karr
     
    Alister Ware, Jul 29, 2011
    #8
  9. rantingrick

    Andrew Berg Guest

    On 2011.07.29 04:21 PM, Alister Ware wrote:
    > instead of all this negativity why don't you try being productive for a
    > change either make a suggestion for an addition (ie something that does
    > not yest exits) or better yet give us all the benefit of your supreme
    > coding talent & provide some code?

    Because trolling the group is apparently more fun, even though most of
    the regulars here know he's trolling.

    --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
     
    Andrew Berg, Jul 29, 2011
    #9
  10. On Sat, Jul 30, 2011 at 6:44 AM, Corey Richardson <> wrote:
    > Excerpts from rantingrick's message of Fri Jul 29 13:22:04 -0400 2011:
    >>  * New path module will ONLY support one path sep!

    >
    > 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.


    Just tested this: You can type c:/foldername into the box at the top
    of a folder in Explorer, and it works. It will translate it to
    c:\foldername though.

    We are not here to talk solely to OSes. We are here primarily to talk
    to users. If you want to display a path to the user, it's best to do
    so in the way they're accustomed to - so on Windows, display
    backslashes.

    >>  - normcase --> path = path.lower()

    >
    > Not quite, here are a few implementations of normcase (pulled from 2.7)
    >
    > # NT
    >    return s.replace("/", "\\").lower()
    >
    > # Mac (Correct in this case)
    >    return path.lower()
    >
    > # POSIX
    >    return s
    >
    > But I can't think of where I would ever use that. Isn't case important on
    > Windows?


    No, as is demonstrated by the three above; case isn't important on
    Windows, but it is on Unix.

    >>  - 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.


    See above, we talk to users.

    > 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.


    Absolutely!
    >>  * 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!


    Agreed that it's an odd name; to me, "basename" means no path and no
    extension - the base name from r"c:\foo\bar\quux.txt" is "quux".
    Unfortunately that's not what this function returns, which would be
    "quux.txt".

    ChrisA
     
    Chris Angelico, Jul 29, 2011
    #10
  11. rantingrick

    Terry Reedy Guest

    On 7/29/2011 1:22 PM, rantingrick wrote:

    > * 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).


    A named tuple would be an even better return, so one could refer to the
    parts as t.drive, etc.
     
    Terry Reedy, Jul 30, 2011
    #11
  12. join 'Python-Dev'-mailinglist and tell them!
    from now on I will just ignore threads you initiated

    does trolling really make that much fun?
    * rantingrick <> [2011-07-29 19:25]:
    >
    > --------------------------------------------------
    > Overview of Problems:
    > --------------------------------------------------
    >
    > * Too many methods exported.
    > * Poor choice of method names.
    > * Non public classes/methods exported!
    > * Duplicated functionality.
    >
    > --------------------------------------------------
    > 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.
    >
    > * 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.
    >
    > --------------------------------------------------
    > Expose of the Warts of current module:
    > --------------------------------------------------
    >
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 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()
    > - normpath --> should not need this!
    > - os --> should be private!
    > + pardir
    > + pathsep
    > + realpath
    > + relpath
    > + sep
    > - split --> path.rsplit('/', 1)
    > - splitdrive --> path.split(':', 1)
    > - splitext --> path.rsplit('.')
    > - splitunc --> 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
    > * split --> split what?
    > * splitext --> Wow, informative!
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 3. Non Public Names Exposed!
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    >
    > * genericpath
    > * os
    > * stat
    > * sys
    > * warnings
    >
    >
    > Note: i did not check the Unix version of os.path for this.
    >
    > ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 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)

    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >


    --
    Michael Poeltl
    Computational Materials Physics voice: +43-1-4277-51409
    Univ. Wien, Sensengasse 8/12 fax: +43-1-4277-9514 (or 9513)
    A-1090 Wien, AUSTRIA cmp.mpi.univie.ac.at
     
    Michael Poeltl, Jul 30, 2011
    #12
  13. Andrew Berg wrote:

    >>>>> os.path.exists(path, ignoreSymLnks=False)

    > I actually agree with you on these, which I suppose is interesting.



    Guido has a rule of thumb: "No constant arguments". Or another way to put
    it: if a function takes an argument which is nearly always a constant
    (usually, but not always, a flag) then it is usually better off as two
    functions.

    Especially if the implementation looks like this:

    def get_thing(argument, flag):
    if flag:
    return one_thing(argument)
    else:
    return another_thing(argument)


    Argument flags which do nothing but change the behaviour of the function
    from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
    idea, but aren't. Consider it a strong guideline rather than a law, but
    it's one I would think very long and hard about before violating.

    But having said that, I'm currently writing a library where nearly all the
    functions violate the No Constant Argument rule. (The API isn't yet stable,
    so I may still change my mind.) Make of that what you will.


    --
    Steven
     
    Steven D'Aprano, Jul 30, 2011
    #13
  14. Teemu Likonen wrote:

    > * 2011-07-29T10:22:04-07:00 * <> wrote:
    >
    >> * New path module will ONLY support one path sep! There is NO reason
    >> to support more than one.

    >
    > Pathnames and the separator for pathname components should be abstracted
    > away, to a pathname object.


    Been there, done that, floundered on the inability of people to work out the
    details.

    http://www.python.org/dev/peps/pep-0355/



    --
    Steven
     
    Steven D'Aprano, Jul 30, 2011
    #14
  15. rantingrick

    Andrew Berg Guest

    Function "modes" vs. separate functions (was: PyWart: os.path needsimmediate attention!)

    On 2011.07.29 07:50 PM, Steven D'Aprano wrote:
    > Especially if the implementation looks like this:
    >
    > def get_thing(argument, flag):
    > if flag:
    > return one_thing(argument)
    > else:
    > return another_thing(argument)
    >

    Well, that would be annoying, but wouldn't it be even more annoying to
    do this:
    def get_one_thing(arg):
    return one_thing(arg)

    def get_another_thing(arg):
    return another_thing(arg)

    > Argument flags which do nothing but change the behaviour of the function
    > from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
    > idea, but aren't. Consider it a strong guideline rather than a law, but
    > it's one I would think very long and hard about before violating.

    Creating separate functions for two thing that do almost the same thing
    seem more of a nuisance to me, especially if they share a lot of code
    that isn't easily separated into other functions.

    --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
     
    Andrew Berg, Jul 30, 2011
    #15
  16. rantingrick

    Andrew Berg Guest

    Re: Function "modes" vs. separate functions

    On 2011.07.29 08:57 PM, Ben Finney wrote:
    > If they share a lot of code, either it *is* separable to common
    > functions (in which case, implement it that way), or the “same thingâ€
    > code is sufficiently complex that it's better to show it explicitly.
    >
    > But this is all getting rather generic and abstract. What specific
    > real-world examples do you have in mind?

    I can't come up with any off the top of my head. I was thinking of a
    general rule anyway; ultimately one decides (or at least should) how to
    write code on a case-by-case basis.

    --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
     
    Andrew Berg, Jul 30, 2011
    #16
  17. On Sat, 30 Jul 2011 07:43:15 +1000, Chris Angelico <>
    declaimed the following in gmane.comp.python.general:


    > Just tested this: You can type c:/foldername into the box at the top
    > of a folder in Explorer, and it works. It will translate it to
    > c:\foldername though.
    >

    So far as I know, the only place that /requires/ the \ is the
    command shell (since / is the "option" introducer). If one uses run-time
    libraries only, and never invokes os.system() or similar, one is free to
    use / all they want.
    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
     
    Dennis Lee Bieber, Jul 30, 2011
    #17
  18. rantingrick

    Terry Reedy Guest

    On 7/29/2011 8:50 PM, Steven D'Aprano wrote:

    > Guido has a rule of thumb: "No constant arguments". Or another way to put
    > it: if a function takes an argument which is nearly always a constant
    > (usually, but not always, a flag) then it is usually better off as two
    > functions.


    I do not really understand his 'rule'*. The stdlib has lots of functions
    with boolean flags and params which default to None and are seldom
    over-ridden.

    * Which is to say, it feels more like his gut feeling applied on a
    case-by-case basis than an actual rule that anyone could apply in any
    objective manner.

    > Especially if the implementation looks like this:
    >
    > def get_thing(argument, flag):
    > if flag:
    > return one_thing(argument)
    > else:
    > return another_thing(argument)


    If the rule is limited to this situation, where no code is shared, it
    seems pretty sensible.

    > Argument flags which do nothing but change the behaviour of the function
    > from Mode 1 to Mode 2 are an attractive nuisance: they seem like a good
    > idea, but aren't. Consider it a strong guideline rather than a law, but
    > it's one I would think very long and hard about before violating.
    >
    > But having said that, I'm currently writing a library where nearly all the
    > functions violate the No Constant Argument rule. (The API isn't yet stable,
    > so I may still change my mind.) Make of that what you will.


    See * above ;-).

    Terry Jan Reedy
     
    Terry Reedy, Jul 30, 2011
    #18
  19. On 2011-07-30, Michael Poeltl <> wrote:
    > join 'Python-Dev'-mailinglist and tell them!
    > from now on I will just ignore threads you initiated
    >
    > does trolling really make that much fun?


    RR must think so, considering how much effort he seems to put into it.
    It is rather amusing to see how many people take him seriously. I
    plonked him ages ago, but thanks to all the people who reply with one
    or two lines and then quote his entire flippin' rant, I still get to
    see most of his posts.

    > * rantingrick <> [2011-07-29 19:25]:


    [100+] lines of unnecessarily quoted bait elided.
     
    Grant Edwards, Jul 30, 2011
    #19
  20. rantingrick

    Andrew Berg Guest

    On 2011.07.30 10:33 AM, Grant Edwards wrote:
    > RR must think so, considering how much effort he seems to put into it.

    He hasn't replied to his last two troll threads, though. It does seem
    odd to write a wall of text and then not respond to replies. To be fair,
    though, most replies either mock him or point out that he's a troll. :D

    --
    CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
     
    Andrew Berg, Jul 30, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. rantingrick
    Replies:
    20
    Views:
    511
    Terry Reedy
    Jul 23, 2011
  2. rantingrick
    Replies:
    0
    Views:
    192
    rantingrick
    Jul 22, 2011
  3. rantingrick
    Replies:
    7
    Views:
    362
    Chris Angelico
    Jul 30, 2011
  4. rantingrick
    Replies:
    1
    Views:
    455
    harrismh777
    Jul 29, 2011
  5. rantingrick
    Replies:
    3
    Views:
    371
    rantingrick
    Sep 14, 2011
Loading...

Share This Page