PEP on path module for standard library

[Reinhold Birkenfeld]

Mike Orr wrote:

> The main changes I'd like to see in Path (some of these have been made
> in Python CVS at nondist/sandbox/path/path.py) are:

Thanks for the comments! They are greatly appreciated.

> - When methods create path objects, use self.__class__() instead of
> Path().
>   This makes it possible to subclass Path.  Otherwise you
>   have to rewrite the whole thing due to the hardcoded name.
>
> - Path.cwd() should be a class method instead of a static method, for
> the same
>   reason.

Changed by now.

> - The constructor behavior in CVS is good.  Path(''), Path.cwd(),
>   Path() => Path.cwd().

Note that Path() results in os.curdir, while Path.cwd() results in the
absolute current directory.

> - Need .chdir() method, otherwise you have to import os for it.

Added by now.

> - Some way to pretty-print paths embedded in lists/dicts as strings.  I
> have a
>   .repr_as_str class attribute that toggles this.

I think str() does its job nicely there.

> - .ancestor(3) is the same as .parent.parent.parent, but more concise.

Good proposal, will consider this.

> - I saw in a thread that .name and .parent were removed.  I use them
> very
>   frequently, along with .ext and .namebase.  I don't want to call
> methods for
>   these.

They are now named .basename and .directory.

> - '/' vs .joinpath(), no big deal.  I've been using '/' because it's
> there.
>   .joinpath must take multiple *args, to prevent .joinpath().joinpath()
> .

That's already in.

> - .joinancestor(N, *components) is a combination of .ancestor and
> .joinpath.
>   If curdir is /home/joe/Webware/www, Path.cwd().joinancestor(1, 'lib')
> is
>   /home/joe/Webware/lib.

I think Path.cwd().parent.joinwith('lib') is readable enough.

> - Keep .lisdir() as in CVS; it acts like os.listdir().  This is useful
> even
>   with paths, when you're just going to use the string basename anyway.

Right. In addition, it's confusing if os.listdir is behaving differently
from Path.listdir().

> - Who needs .open()?  open(myPath) is fine.  But it can stay for
> backward
>   compatibility.

Right. I think it's nice for people who like a more OO approach.

> Less important but non-controversial:
>
> - Path.tempfile(), Path.tempdir():
>   Create a temporary file using tempfile.mkstemp, tempfile.mkdtemp
>
> - Path.tempfileobject():
>   Create a temporary file object using tempfile.TemporaryFile.
>   (Static method.)

Don't know whether these belong here. They are all not acting upon the
path, but create the file/dir at another location.

> Controversial:
>
> - Delete methods and mkdir should succeed silently if the operation is
>   already done.  Otherwise you always have to put them in an if:
>   'if foo.exists(): foo.remove()'.

That's a good thing. The delete methods shouldn't act any different from
the corresponding os functions.

> - .delete_dammit() recursively deletes it, whatever it is, without you
>   having to do the if file/if directory dance.  I suppose it would need
> a
>   politically correct name.
>   which you really have to do every time you delete.

*grin* Any naming suggestions?

> - All .dirs*, .files*, .walk* methods have a symlinks flag, default
> True.
>   If false, don't yield symlinks.  Add .symlinks and .walksymlinks
> methods.
>   This eliminates an 'if' for programs that want to treat symlinks
> specially.

Sounds good. Will see.

Reinhold