There's kind of a lot of methods in here, which is a little bothersome. It also points towards the motivation for the class -- too many options in too many places in the stdlib. But throwing them *all* in one class consolidates but doesn't simplify, especially with duplicate functionality.
I'm not strongly advocating any of the methods below be removed, but at least it seems like it should be discussed. By not removing any it is easier to translate the os.path (and other) forms. I imagine it will be a long time before those forms go away, though, so I don't know how useful it is to plan for a speedy and seamless transition. BJörn Lindqvist wrote: > This class defines the following public methods: > > # Special Python methods. > def __new__(cls, init = os.curdir): ... > def __repr__(self): ... > def __add__(self, more): ... > def __radd__(self, other): ... > def __div__(self, rel): ... > def __truediv__(self, rel): ... > > # Alternative constructor. > def cwd(cls): ... > > # Operations on path strings. > def abspath(sef): ... > def normcase(self): ... > def normpath(self): ... > def realpath(self): ... > def expanduser(self): ... > def expandvars(self): ... This is equivalent to p.__class__(string.Template(p).safe_substitute(os.environ)). Obviously that form is a lot longer, but maybe usefully more explicit. Well, it is a *lot* longer. But if string.Template's functionality becomes a method on str (is that the plan?) then this won't be so bad. Also if string.Template returns an object of the same class as is passed in. Then maybe it'd just be p.safe_substitute(os.environ), which isn't bad at all. Maybe if this used Windows conventions on that platform -- of %VAR% -- it would seem more useful. Though I think $VAR should still work on both platforms regardless (just like / does). > def dirname(self): ... > def basename(self): ... These are duplicated as properties. basename and namebase are confusing alternatives to each other. > def expand(self): ... I see this is a combination of normpath, expanduser, and expandvars. Useful, certainly. But there's also a lot of forms, and no one applies these operations consistently it seems. > def splitpath(self): ... > def splitdrive(self): ... > def splitext(self): ... > def stripext(self): ... This is another new method, equivalent to .splitext()[0]. I'm not sure it's that important. > def splitunc(self): ... [1] > def joinpath(self, *args): ... > def splitall(self): ... And there's just so many splitting functions. Could these somehow be combined? Maybe returning a tuple/struct? Or maybe just relying on properties. > def relpath(self): ... > def relpathto(self, dest): ... These don't feel compellingly different according to the name. I find the cwd fragile too, so maybe the first form offends me from that perspective too. Just the explicit form feels sufficient to me, and unambiguous as both a reader and writer of code. > # Properties about the path. > parent, name, namebase, ext, drive, uncshare[1] Actually, I see namebase is actually the name without an extension. It seems ambiguous to me just from the names, and I'd rather both weren't there. Though ext somehow seems useful and unambiguous in a way namebase isn't. Not sure why. It's unclear which of these should be Paths. Of course parent should. None of the others? When methods return paths and when they return strings is an important part of the spec. > # Operations that return lists of paths. > def listdir(self, pattern = None): ... > def dirs(self, pattern = None): ... > def files(self, pattern = None): ... > def walk(self, pattern = None): ... > def walkdirs(self, pattern = None): ... > def walkfiles(self, pattern = None): ... Notably these aren't like os.path.walk, I assume. Which is fine by me. > def match(self, pattern): > def matchcase(self, pattern): I don't see these methods in the path class, and I'm not sure what they'd do. > def glob(self, pattern): > > # Methods for retrieving information about the filesystem > # path. > def exists(self): ... > def isabs(self): ... > def isdir(self): ... > def isfile(self): ... > def islink(self): ... > def ismount(self): ... > def samefile(self, other): ... [1] > def getatime(self): ... > def getmtime(self): ... > def getctime(self): ... > def getsize(self): ... > def access(self, mode): ... [1] > def stat(self): ... > def lstat(self): ... > def statvfs(self): ... [1] The stat and get* functions overlap too. I.e., p.getmtime() and p.stat().st_mtime are the same. Too bad about the st_* names on stat objects, otherwise I don't see any problem with using that directly. It still seems clearer. > def pathconf(self, name): ... [1] I can't figure out what this does, even from the docs. Some of these seem obscure enough they could be left in os. > def utime(self, times): ... > def chmod(self, mode): ... > def chown(self, uid, gid): ... [1] > def rename(self, new): ... > def renames(self, new): > > # Filesystem properties for path. > atime, getmtime, getctime, size Mmm... then these show up yet again. > # Methods for manipulating information about the filesystem > # path. > def utime(self, times): ... > def chmod(self, mode): ... > def chown(self, uid, gid): ... [1] > def rename(self, new): ... > def renames(self, new): ... Dups in the spec. > # Create/delete operations on directories > def mkdir(self, mode = 0777): ... > def makedirs(self, mode = 0777): ... > def rmdir(self): ... > def removedirs(self): ... > > # Modifying operations on files > def touch(self): ... > def remove(self): ... > def unlink(self): ... > > # Modifying operations on links > def link(self, newpath): ... > def symlink(self, newlink): ... > def readlink(self): ... > def readlinkabs(self): ... > > # High-level functions from shutil > def copyfile(self, dst): ... > def copymode(self, dst): ... > def copystat(self, dst): ... > def copy(self, dst): ... > def copy2(self, dst): ... > def copytree(self, dst, symlinks = True): ... > def move(self, dst): ... > def rmtree(self, ignore_errors = False, onerror = None): ... > > # Special stuff from os > def chroot(self): ... [1] > def startfile(self): ... [1] Like pathconf, maybe these don't need to be moved into the module, and can be left in os. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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
