Posted to python-dev and python-3000. Follow-ups to python-dev only please.
On 10/31/06, Fredrik Lundh <[EMAIL PROTECTED]> 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. -- Mike Orr <[EMAIL PROTECTED]> _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
