[Python-Dev] The path module PEP

[Jason Orendorff]

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