Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh
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("foo")
Path( Path("directory"), "subdirectory", "file") # Replaces
.joinpath().
Path()
Path.cwd()
Path("ab") + "c" => Path("abc")
.abspath()
.normcase()
.normpath()
.realpath()
.expanduser()
.expandvars()
.expand()
.parent
.name # Full filename without path
.namebase # Filename without extension
.ext
.drive
.splitpath()
.stripext()
.splitunc()
.uncshare
.splitall()
.relpath()
.relpathto()
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