PRE-PEP: new Path class

[John Roth]

"Mike C. Fletcher" <mcfletch at rogers.com> wrote in message
news:mailman.118.1073338659.12720.python-list at python.org...
> John Roth wrote:
> ...
>
> >1) Should path be a subclass of str?
> >
> >No. Outside of the difficulty of deciding whether it's a
> >subclass of single byte or unicode strings, it's a pure
> >and simple case of Feature Envy. Granted, there will
> >be times a developer wants to use string methods, but
> >the most common operations should be supported directly.
> >
> >
> It's not the methods that make me want to use str/unicode as the base,
> it's the ability to pass the resulting instances to built-in methods
> that explicitly expect/require str/unicode types.  Not sure how many of
> the core functions/libraries still have such requirements, but I'd guess
> it's a few.
>
> That said, I don't mind making path it's own base-class, I just *really*
> want to be able to pass them to path-unaware code without extra coercian
> (otherwise switching a module to *producing* paths instead of raw
> strings will cause the *clients* of that module to break, which is a
> serious problem for rapid adoption).

That's an excellent point, but it begs the question of which
string class it should subclass. Unless it's got some way of
changing its base class depending on the system it's running
on. That, in turn, probably violates the Principle of Least
Astonishment.

> >5) Should == operator be the same as os.path.samefile()?
> >
> >Why not...
> >
> >
> __eq__ sounds about right.  I gather this call goes out to the
> filesystem first, though.  Might be good to first check for absolute
> equality (i.e. the same actual path) before doing that.

I think this has to do with "conceptual integrity." Are we talking
about a path object that happens to have the ability to do file
system operations in appropriate circumstances, or are we talking
about a file system object that includes all of the usual path
manipulations? You seem to be thinking of the first approach,
and I'm thinking of the second. You're beginning to convince me,
though.

> >7) Should the various gettime methods return Datetime
> >objects.
> >
> >Of course.
> >
> >
> What are we doing for Python 2.2 then?  I agree with the principle, but
> we should likely have a fallback when datetime isn't available.

Do we care? If this is going into Python, it will be in 2.4 at the
earliest, with a possible addon to a late 2.3 release. I don't see
it going into 2.2 at all, although a backwards version would
be nice.

> >10) Commonprefix, walk and sameopenfile?
> >
> >Commonprefix should be a string or list method,
> >it doesn't fit here.
> >
> >
> Path commonprefix are different operations from str commonprefix.  Paths
> should only accept entire path-segments (names) as being equal, while
> strings should accept any set of characters:
>
>     '/this/that/those/them'
>     '/this/thatly/those/them'
>
> should see '/this/' as the commonprefix for the paths, not '/this/that'.

Good point if you're thinking of heterogenous collections. If you're
thinking (as I am) that an object can represent a directory, then it
seems like a singularly useless method.

> >walk is a nice function, but it should be redone to
> >use the visitor pattern directly, with different method
> >names for files, directories and whatever else a
> >particular file system has in it's warped little mind.

> Reworking walk is probably a good idea.  I'll let others worry about it,
> as I've re-implemented the functionality so many times for my own code
> that I'm just sick of it :) .

I can understand that. [grin]

> >13) chdir, chmod, etc?
> >
> >No. This has nothing to do with pathname.
> >
> >
> chmod has to do with altering the access mode of a file/directory by
> specifying it's path, no?  Seems like it could readily be a method of
> the path.

Right. I forgot that these are two totally different issues.

> chdir should accept a path, otherwise doesn't seem like it
> should be a method.

If the path object describes a directory, then I'd see
a .chdir() method as useful. Otherwise, it belongs
somewhere else, although I don't have a clue where
at the moment.

>
> Enjoy all,
> Mike

John Roth