[Python-Dev] Alternative path suggestion

[Mike Orr]

On 5/6/06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Greg Ewing wrote:
> > Nick Coghlan wrote:
> >
> >> So I suggest splitting the internal data into 'path elements separated
> >> by os.sep', 'name elements separated by os.extsep'
> >
> > What bothers me about that is that in many systems
> > there isn't any formal notion of an "extension",
> > just a convention used by some applications.
> >
> > Just because I have a "." in my filename doesn't
> > necessarily mean I intend what follows to be
> > treated as an extension.

Good points, Nick and Greg.  Splitting directories is unambiguous and
makes the API much simpler.  But filename extensions are just a
convention.  The user may want all, some, or no extensions split. 
With os.splitext() the user is explicitly saying, "Split this number
of extensions on this particular file."  We we should not presume to
automate this.

How about:

    .splitext(max_exts=1)    =>   (filename, list_of_extensions)

Another good idea yesterday:

    p.parent(2)                 # Fulfills my .ancestor() proposal.

> This is an interesting point - I've been tinkering with this a bit (despite my
> best intentions about not getting distracted by the topic ;), and it's
> starting to look like treating directory paths and file paths identically
> poses significant problems for an object-oriented API.
>
> For example, appending a filename or a relative directory path to an existing
> directory path is fine (giving a filename or directory path as the result),
> but you can't do either to a filename.
>
> Listing the entries or walking a file doesn't make any sense either.
>
> And extension information is typically significant only for filenames, not for
> directories.
>
> When paths are just strings, the distinction doesn't matter because the
> instances have no inherent behaviour - it is the application that carries the
> state regarding whether something is meant to be a directory name or a file name.
>
> So it makes a lot more sense to have separate Dirpath and Filepath (and
> possibly Linkpath) objects - from an OO point of view, the methods provided
> for each of these kinds of filesystem entities will be significantly
> different. A common parent Path object may still make sense if there's
> sufficient overlap, though (e.g. retrieving status related information).

Very interesting.  The user knows whether he wants a file or
directory, so why not force him to specify?  Then we can have a
standard exception if the actual filesystem object is inconsistent
with the spec.

--
Mike Orr <sluggoster at gmail.com>
(mso at oz.net address is semi-reliable)