PEP on path module for standard library

[Mike Orr]

Sorry for the formatting of my first message; I haven't posted via
Google Groups before.

Reinhold Birkenfeld wrote:
> > - 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.

But when you str() a list or other collection, it repr()'s the
elements.  This makes programs difficult to debug because you can't
just insert a "print my_list"; you then have to weed through all the
"path(" prefixes in the output.    So you have to write a custom for
loop, which you may only use for five minutes, to convert the paths or
print them separately.  With a list you can use a list comprehension,
but not with a more complex structure.

I don't know if there's a good solution to this other than a path_debug
function that takes an object and converts all the embedded paths to
strings,
because people would object to repr() returning a plain string, but I
want to at least acknowledge it's a problem.

> > 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.

More controversial than I thought.  OK, they can stay in a subclass.

My reasoning is that, if you're using paths, you'll need a Path for the
file/dir anyway, so why not do it in one step?  It also organizes the
operations, the way Path organizes os.path and shutil.  tempfileobject
is less closely related to path, but it would allow the deprecation of
the tempfile module, rather than just two functions in it.

> > 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.

Jason said the same thing.  I disagree.  But it shows why a "literal"
superclass in the stdlib and higher-level subclasses would be useful.

I don't see why a little change to avoid an unnecessary IOError is a
bad thing.  The only programs it would hurt are those that really want
to know whether the thing already existed, and those programs can
explicitly test for it *and already do*.  But most programs just want
to make sure the way is clear for their files, and would like a
one-line call to do it.

-- Mike Orr <mso at oz.net>