[Python-Dev] Path object design (original) (raw)

Fredrik Lundh fredrik at pythonware.com
Wed Nov 1 08:45:06 CET 2006

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.(string)" functions or the "" wrapper. To manipulate objects identified by a path, given either as a string or a path wrapper, use "os.(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.

More information about the Python-Dev mailing list