[Python-Dev] Path object design

[Fredrik Lundh]

Talin wrote:

> I'm right in the middle of typing up a largish post to go on the 
> Python-3000 mailing list about this issue. Maybe we should move it over 
> there, since its likely that any path reform will have to be targeted at 
> Py3K...?

I'd say that any proposal that cannot be fit into the current 2.X design 
is simply too disruptive to go into 3.0.  So here's my proposal for 2.6 
(reposted from the 3K list).

This is fully backwards compatible, can go right into 2.6 without 
breaking anything, allows people to update their code as they go,
and can be incrementally improved in future releases:

     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.

     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.

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.

With this in place in 2.6 and 2.7, all that needs to be done for 3.0 is 
to remove (some of) the old cruft.

</F>