[path-PEP] Path inherits from basestring again

[Reinhold Birkenfeld]

Peter Hansen wrote:
> Reinhold Birkenfeld wrote:
> [on comparing Paths and stings]
>> Do you have a use case for the comparison? Paths should be compared only
>> with other paths.
> 
> I can think of lots, though I don't know that I've used any in my 
> existing (somewhat limited) code that uses Path, but they all involve 
> cases where I would expect, if comparisons were disallowed, to just wrap 
> the string in a Path first, even though to me that seems like it should 
> be an unnecessary step:
> 
>    if mypath.splitpath()[0] == 'c:/temp':
> 
>    if 'tests' in mypath.dirs():
> 
>    and lots of other uses which start by treating a Path as a string
>    first, such as by doing .endswith('_unit.py')

endswith is okay, since it is an inherited method from str.

> Any of these could be resolved by ensuring both are Paths, but then I'm 
> not sure there's much justification left for using a baseclass of 
> basestring in the first place:
> 
>    if mypath.splitpath()[0] == Path('c:/temp'):

But you must admit that that't the cleaner solution.

>    if Path('tests') in mypath.dirs():
> 
> Question: would this latter one actually work?  Would this check items 
> in the list using comparison or identity?  Identity would simply be 
> wrong here.

Yes, it works. I didn't do anything to make it work, but Path seems to inherit
the immutableness from str.

> [on removing properties in favour of methods for volatile data]
>> My line of thought is that a path may, but does not need to refer to an
>> existing, metadata-readable file. For this, I think a property is not
>> proper.
> 
> Fair enough, though in either case an attempt to access that information 
> leads to the same exception.  I can't make a strong argument in favour 
> of properties (nor against them, really).

Okay.

>> What about iteration and indexing? Should it support
>> "for element in path" or "for char in path" or nothing?
> 
> As John Roth suggests, the former seems a much more useful thing to do. 
>   The latter is probably as rarely needed as it is with regular strings 
> (which I believe is roughly "never" in Python).
> 
> [on .read_file_bytes() etc]
>> I think it is not exactly bad that these names are somehow outstanding,
>> as that demonstrates that something complex and special happens.
> 
> Point taken.  What about ditching the "file" part, since it is redundant 
> and obvious that a file is in fact what is being accessed.  Thus: 
> .read_bytes(), .read_text(), .write_lines() etc.

Hm. Is it so clear that a it's about a file? A path can point to anything,
so I think it's better to clearly state that this is only for a file at the
path, if it exists.

Reinhold