[Python-Dev] Mini Path object
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
So, let's say we strip this Path class to:
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