[path-PEP] Path inherits from basestring again

[Reinhold Birkenfeld]

Peter Hansen wrote:
> 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?

All of these. Do you need them?

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

No. But the size of a file is somewhat volatile, and does not feel like
a "property" of the path to it. Remember: the path is not the file. Same
goes with the xtime() methods.

Different is the basename/directory/etc.: as long as the path stays the same,
these properties will stay the same.

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

Well, I think that's right. Will change back to dirs().

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

At the moment, I think about overriding certain string methods that make
absolutely no sense on a path and raising an exception from them.

>> * Default constructor: Path() == Path(os.curdir)
> 
> To construct an empty path then one can still do Path('') ?

Yes.

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

It has even been suggested to throw them out, as they don't have so much to
do with a path per se. When the interface is too burdened, we'll have less
chance to be accepted. Renaming these makes clear that they are not operations
on the path, but on a file the path points to.

Phillip J. Eby suggested these to be set_file_xxx and get_file_xxx to demonstrate
that they do not read or write a stream; how about that?

Reinhold