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
--
http://mail.python.org/mailman/listinfo/python-list
