[Python-Dev] Mini Path object

Mike Orr sluggoster at gmail.com
Thu Nov 2 07:47:54 CET 2006

Posted to python-dev and python-3000.  Follow-ups to python-dev only please.

On 10/31/06, Fredrik Lundh <fredrik at pythonware.com> wrote:
>   here's mine; it's fully backwards compatible, can go right into 2.6,
> 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.

Given the widely-diverging views on what, if anything, should be done
to os.path, how about we make a PEP and a standalone implementation of
(1) for now, and leave (2) and everything else for a later PEP.  This
will make people who want a reasonably forward-compatable object NOW
for their Python 2.4/2.5 programs happy, provide a common seed for
more elaborate libraries that may be proposed for the standard library
later (and eliminate the possibility of moving the other functions and
later deprecating them), and provide a module that will be well tested
by the time 2.6 is ready for finalization.

There's already a reference implementation in PEP 355, we'd just have
to strip out the non-pathname features.  There's a copy here
(http://wiki.python.org/moin/PathModule) that looks reasonably recent
(constructors are self.__class__() to make it subclassable), although
I wonder why the class is called path instead of Path.  There was
another copy in the Python CVS  although I can't find it now; was it
deleted in the move to Subversion?  (I thought it was in
/sandbox/trunk/: http://svn.python.org/view/sandbox/trunk/).

So, let's say we strip this Path class to:

class Path(unicode):
    Path(  Path("directory"),   "subdirectory", "file")    # Replaces
    Path("ab") + "c"  => Path("abc")
    .name                 # Full filename without path
    .namebase        # Filename without extension

Would this offend anyone?  Are there any attribute renames or method
enhancements people just can't live without?  'namebase' is the only
name I hate but I could live with it.

The multi-argument constructor is a replacement for joining paths.
(The PEP says .joinpath was "problematic" without saying why.)    This
could theoretically go either way, doing either the same thing as
os.path.join, getting a little smarter, or doing "safe" joins by
disallowing "/" embedded in string arguments.

I would say that a directory-tuple Path object with these features
could be maintained in parallel, but since the remaining functions
require string arguments you'd have to use unicode() a lot.

Mike Orr <sluggoster at gmail.com>

More information about the Python-Dev mailing list