PEP on path module for standard library

[Reinhold Birkenfeld]

FYI: I modified the path module a bit so that it fits many of the suggestions
from python-dev, and put the result in the Python CVS tree under
nondist/sandbox/path.

Most prominent change is that it doesn't inherit from str/unicode anymore.
I found this distinction important, because as a str subclass the Path object
has many methods that don't make sense for it.

Peter Hansen wrote:
> Michael Hoffman wrote:
>> For the PEP, do any of you have arguments for or against including path? 
>> Code samples that are much easier or more difficult with this class 
>> would also be most helpful.
> 
> I believe the strongest argument for "path" can be made for how it 
> integrates functionality which, although closely related conceptually, 
> is currently distributed across a half dozen or more different modules 
> in the standard library.  Especially for newbies (I can only imagine, at 
> this stage) it would make working with files much easier in a many ways.
> 
> "Easier" or "more difficult" is a subjective thing, of course, but one 
> can't argue with the fact that path can sometimes do through a single 
> object what would otherwise require several imports and a bunch of calls 
> into things like open(), os.path, grep, and shutil.

Correct.

> Examples showing effective uses of path that simplify those cases would 
> probably merit the label "easier" even in Guido's mind, though 
> unfortunately that's not certain.  "Easier" in some minds might simply 
> translate to "many lines less code", and while path can sometimes do 
> that, aside from the ease of splitting and joining stuff without 
> multiple calls to os.path.this-and-that, it really doesn't often reduce 
> code size _that_ much, in my experience.  (Postings to c.l.p showing a 
> 50% reduction in code size for contrived examples notwithstanding.)

Well, these examples are the ones we'd like to see here. So, people:
If you posted examples to c.l.py in the past, please try to collect
them here!

> A related thoughts: since paths are objects, they have attributes or 
> properties, and having things like ".basename" and ".parent" readily 
> available without having to do obscure things like 
> os.path.split(somepath)[0] makes things much easier to read (therefore 
> more maintainable).  In fact, I'd propose that as another strong 
> argument in path's favour: it makes code much more readable, even if not 
> "easier" to write.
> 
> Hmm... does "easier" or "more difficult" apply to the writing of the 
> code or the reading of it?  I find it self-evident that code written 
> using "path" is much easier to read, not necessarily much easier to 
> write (for non-newbies).

And it is much more "Pythonic" in my eyes. Though that word may be inaccurate
when it comes from someone else that Guido, I feel that endless chains of
'[os.path.join(os.path.join(z, "a"), x) for x in os.path.listdir(os.path.join(z, "a") if os.path.isfile(os.path.join(....
are not qualified as being Pythonic.

> I'd summarize this by saying that the integration of "path" in the 
> stdlib would make it easier for newbies to write code (that might not be 
> obvious to a non-newbie... shall we ask some to help?), and easier for 
> everyone to read code (self-evident, no?), and if that's not a 
> sufficient condition for inclusion I don't know what is.

Reinhold