[Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings?

[Andrew Barnert]

On Mar 24, 2015, at 6:44 AM, Tal Einat <talent at gmail.com> wrote:
> 
> On Tue, Mar 24, 2015 at 2:39 PM, Markus Unterwaditzer
> <markus at unterwaditzer.net> wrote:
>> 
>> I'd suggest that an additional property is added where:
>> 
>> Path("/usr/bin/true").newproperty == (Path("/"),
>> Path("/usr"),
>> Path("/usr/bin"),
>> Path("/usr/bin/true"))
>> 
>> I.e. each part is a prefix of the next one.
> 
> Path.parents already exists:
> 
> Python 3.4.2 (default, Feb 23 2015, 21:16:28)
> [GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import pathlib
>>>> list(pathlib.Path("/usr/bin/true").parents)
> [PosixPath('/usr/bin'), PosixPath('/usr'), PosixPath('/')]

Ooh, forgot about that!

That implies a conceptually simpler implementation: it's just first(last(takewhile(all_equal(reversed(map(parents)))))), but I'm too tired to finish translating that from Haskelly terms to itertoolsy terms in my head. :) I'm not sure if that would be simpler (or more efficient) in practice, however.

Also, it would give the opposite answer to is the 'true' bit a potential part of the result if you common-prefix /usr/bin/true with itself (or only pass one argument), which goes nicely with my intuition but not so nicely with the rosettacode page. But maybe that's just a matter of naming--with "common_parent" or "common_ancestor" instead of "common_prefix" it seems pretty obvious and unambiguous?