[Python-3000] Mini Path object

[Mike Orr]

On 11/26/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 11/26/06, Mike Orr <sluggoster at gmail.com> wrote:
> > I tried to make a separate PathAlgebra class and FSPath class, but it
> > got so unweildly to use I made the latter a subclass.  They're now
> > called PathName and Path.
>
> This makes sense to me.  An FSPath without path algebra is basically a
> "directory listing"  That might be a useful abstraction on its own, or
> it might be too much purity.

It's a single path, actually, upon which you can call filesystem operations.
    p.mkdir(), p.copytree(), p.read_file(), p.readlink(), p.listdir()

What you *can't* do is extract/alter the pathname itself using FSPath
operations.
    p.ext, p + ".gz", p.expand_user()    # Error!  Use p.path.ext instead.

Nobody has specifically asked for a FSPath class.  But some people are
adamant they want a PathAlgebra class, a clear separation between
pathname vs filesystem operations. Otherwise we'd just use the earlier
implementations which combine both in one class.  One proposal is to
put PathAlgebra in os.path and not have a FSPath class in the stdlib
at all.  That's not my ideal but it may be small enough and
non-controversial enough to get into Python 2.6, and then we can build
a more elaborate FSPath on top of it for 3.0 (or not).

> C: without a slash is effectively a mount point into the current
> directory.

That's what I always thought "C:foo" is.  But Glyph said it's more
complicated than that:

'"C:blah" does not mean what you think it means on Windows.
Regardless of what you think it means, it is not that.  I thought I
understood it once as the current process having a current directory
on every mapped drive, but then I had to learn about UNC paths of
network mapped drives and it stopped making sense again.'

[python-dev message dated 2006-Nov-1, subject: Path object design,
from glyph at divmod.com]

-- 
Mike Orr <sluggoster at gmail.com>