[Python-Dev] The path module PEP (original) (raw)

Jason Orendorff jason.orendorff at gmail.com
Tue Jan 24 22🔞30 CET 2006

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 <bjourne at gmail.com> 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

More information about the Python-Dev mailing list