Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh firstname.lastname@example.org 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("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.
On 11/2/06, Mike Orr email@example.com wrote:
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.
Why write a PEP at this stage? Just release your proposal as a module, and see if people use it. If they do, write a PEP to include it in the stdlib. (That's basically what happened with the original PEP - it started off proposing Jason Orendorff's path module IIRC).
From what you're proposing, I may well use such a module, if it helps
:-) (But I'm not sure I'd vote for it in to go the stdlib without having survived as an external module first)
Mike Orr wrote:
.abspath() .normpath() .realpath() .splitpath() .relpath() .relpathto()
Seeing as the whole class is about paths, having "path" in the method names seems redundant. I'd prefer to see terser method names without any noise characters in them.