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

[Tal Einat]

On Tue, Mar 24, 2015 at 4:56 PM, Andrew Barnert <abarnert at yahoo.com> wrote:
> On Mar 24, 2015, at 6:44 AM, Tal Einat <talent at gmail.com> wrote:
>> 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?

Well, the function I wrote was "common_parent" since that was what I
needed, and what it does is indeed clearer than "common_prefix". Off
the top of my head, I can't think of use cases where one would want
"common_prefix" instead of "common_parent" where Path.relative_to()
wouldn't be better. So maybe just provide "common_parent"?

- Tal Einat