> The biggest conceptual change is that my path object is a subclass of > ''tuple'', not a subclass of str. For example,
Using tuples is a nice idea! Object paths using tuples is a somewhat common concept. I don't see an immediate reason to be a *subclass* of tuple, though, as opposed to using it as an internal representation. > {{{ > p.normpath() -> Isn't needed - done by the constructor > p.basename() -> p[-1] > p.splitpath() -> (p[:-1], p[-1]) > p.splitunc() -> (p[0], p[1:]) (if isinstance(p[0], path.UNCRoot)) > p.splitall() -> Isn't needed > p.parent -> p[:-1] > p.name -> p[-1] > p.drive -> p[0] (if isinstance(p[0], path.Drive)) > p.uncshare -> p[0] (if isinstance(p[0], path.UNCRoot)) > > and of course: > p.join(q) [or anything like it] -> p + q > }}} Nice indeed. > The only drawback I can see in using a logical representation is that > giving a path object to functions which expect a path string won't > work. The immediate solution is to simply use str(p) instead of p. The > long-term solution is to make all related functions accept a path > object. Let's use __path_.. I mean, generic functions! ;-) (...) > * A ''relative path'' is a path without a root element, so it can be > concatenated to other paths. > * An ''absolute path'' is a path whose meaning doesn't change when > the current working directory changes. That sounds right. > == Easier attributes for stat objects == > > The current path objects includes: > * isdir, isfile, islink, and - > * atime, mtime, ctime, size. (...) This indeed shouldn't be attributes of path, IMO, since they are operations that depend on the state of the filesystem, and will change behind your back. > I think that isfile, isdir should be kept (along with lisfile, > lisdir), since I think that doing what they do is quite common, and > requires six lines: I don't agree. "isdir" is an attribute of the filesystem, not of the path object. I'd never expect that e.g. a network operation could result from accessing an attribute in Python, and that could certainly happen if the path is referencing a network filesystem. -- Gustavo Niemeyer http://niemeyer.net _______________________________________________ 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