[path-PEP] Path inherits from basestring again

[Peter Hansen]

Reinhold Birkenfeld wrote:
> One thing is still different, though: a Path instance won't compare to a regular
> string.

Could you please expand on what this means?  Are you referring to doing 
< and >= type operations on Paths and strings, or == and != or all those 
or something else entirely?

> Other minor differences, as requested on python-dev, are:
> 
> * size property -> getsize() method.
> * atime/mtime/ctime properties -> atime()/mtime()/ctime() methods

What does this mean?  The .size property and a getsize() method both 
already exist (in my copy of path.py anyway) and do the same thing. 
Same with the other ones mentioned above.  Is someone working from an 
out-of-date copy of path.py?

> * dirs() method -> subdirs() method

Given that .files() exists, and returns a list of the files contained in 
a path which represents a folder, why would one want to use subdirs() 
instead of just dirs() to do the same operation for contained folders?
If subdirs() is preferred, then I suggest subfiles() as well.  Otherwise 
the change seems arbitrary and ill-conceived.

> * joinpath() method -> added alias joinwith()
> * splitall() method -> parts() method

This reminds me of the *one* advantage I can think of for not 
subclassing basestring, though it still doesn't make the difference in 
my mind:  strings already have "split()", so Jason had to go with 
"splitpath()" for the basic split operation to avoid a conflict.  A 
minor wart I guess.

> * Default constructor: Path() == Path(os.curdir)

To construct an empty path then one can still do Path('') ?

> * staticmethod Path.getcwd() -> Path.cwd()
> 
> * bytes() / lines() / text() -> read_file_{bytes,lines,text} methods
> * write_{bytes,lines,text} -> write_file_{bytes,lines,text} methods

Under Linux isn't it possible to open and read from directories much as 
with files?  If that's true, the above would seem to conflict with that 
in some way.  As with the the .subdirs() suggestion above, these changes 
seem to me somewhat arbitrary.  .bytes() and friends have felt quite 
friendly in actual use, and I suspect .read_file_bytes() will feel quite 
unwieldy.  Not a show-stopper however.

-Peter