[Python-3000] Path Reform: Get the ball rolling

[Mike Orr]

On 10/31/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>  > Why is 'split' in os.path but 'stat' and 'mkdir' and 'remove' are in
>  > os?  Don't they all operate on paths?
>
> no.  are you saying that you're unable to see the conceptual difference
> between a name and an object?

I see the difference between modifying a path name (which doesn't
depend on the filesystem) vs doing something with it (which requires
the file to exist and be the right type).  But both os and os.path
contain both of these operations.

>     1) add a pathname wrapper to "os.path", which lets you do basic
>        path "algebra".  this should probably be a subclass of unicode,
>        and should *only* contain operations on names.

I assume this means the P.parent and P.join("lib") functionality that
I and others have been clamoring for.

>     2) make selected "shutil" operations available via the "os" name-
>        space; the old POSIX API vs. POSIX SHELL distinction is pretty
>        irrelevant.  also make the os.path predicates available via the
>        "os" namespace.

I assume this means os.path.is*(), os.path.get*(), and shutil.* would
be duplicated in the os module, as well as os.path.exists and
os.path.lexists.  os.walk() already supercedes os.path.walk(),
although I find neither of these as convenient as a generator yielding
individual path objects for every file and/or directory.

> this gives a very simple conceptual model for the user; to manipulate
> path *names*, use "os.path.<op>(string)" functions or the "<path>"
> wrapper.  to manipulate *objects* identified by a path, given either as
> a string or a path wrapper, use "os.<op>(path)".  this can be taught in
> less than a minute.

It would be better than the current situation at least.  It's mainly
the name-manipulation functions that are nested, and thus in need of
an OO paradigm and method chaining (P.basename().splitext()[0]).
Object-manipulation functions can't really be nested so OO isn't as
critical, although os.stat() is nested sometimes.

By the way, the whole stat concept is arbitrary too.  Just because C
makes some operations dependent on stat() doesn't mean we necessarily
should.  In that vein, the os.path.is* and os.path.get* functions are
an improvement. However, there is one good thing about stat():
P.stat().mtime and P.lstat().mtime look a lot better than P.mtime()
and P.lmtime() -- especially considering the two dozen other
functions/methods that would accompany the latter.

-- 
Mike Orr <sluggoster at gmail.com>