Thanks for doing this. I'm not sure anyone that matters here is actually keen on path, but I guess we'll see. A few comments:
On 1/24/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > The following points summarizes the design: > > - Path extends from string, therefore all code which expects > string pathnames need not be modified and no existing code will > break. Actually, I would prefer a Path that *didn't* subclass string, and a new "%p" format-thingy in PyArg_ParseTuple(). %p would expect either a Path object or a string. Stdlib C functions that take paths would be changed from using %s or %u to %p. This would pretty much eliminate the need for path objects to act like strings (except where __cmp__, __hash__, and common sense dictate). The only reason I didn't do this in path.py is that I don't have the required write access to the Python source tree. ;) Subclassing str/unicode seemed like the next best thing. > [...]omitted: > * Function for opening a path - better handled by the builtin > open(). Aside: I added this to support a few people who liked the idea of "openable objects", meaning anything that has .open(), analogous to "writeable objects" being anything with .write(). I don't use it personally. Examples 1 and 2 have errors. In example 1, the "after" code should be: d = path('/usr/home/guido/bin') for f in d.files('*.py'): f.chmod(0755) In example 2, the "before" code is missing a line -- the call to os.path.walk(). (Actually it should probably use os.walk(), which looks much nicer.) I suspect you'll be asked to change the PEP to remove __div__ for starters, in which case I propose using the Path constructor as the replacement for os.path.join(). In that case, Path.joinpath can be dropped. -j _______________________________________________ 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