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

[Markus Unterwaditzer]

No, I always forget. I've forwarded the message.

I understand that the current behavior creates bugs too, however, I'd say the drawbacks I described are much bigger.

The next option would be to create a separate type for path segments which has the appropriate comparison behavior: PathSegment, or more generically, PathString.

On 24 March 2015 13:37:34 CET, Paul Moore <p.f.moore at gmail.com> wrote:
>On 24 March 2015 at 12:25, Markus Unterwaditzer
><markus at unterwaditzer.net> wrote:
>> I'd say treating each part as full-blown Path doesn't make sense from
>a semantical POV.
>>
>> Simply mapping Path over the results is also a potential source of
>bugs, since each part is now a relative path to the CWD, instead of the
>previous segment.
>
>Fair point. Although I tend to view them as just "relative" - to what
>depends on context (in this case, "to the preceding bits in the list"
>is implied). But I agree, people may not be expecting that and so
>could make mistakes.
>
>I still think using strings is equally a bug magnet, though. There's
>actually no clean way of getting the correct case sensitivity
>behaviour *apart* from making the parts into path objects.
>
>I don't think your suggestion of each part being a prefix of the next
>would actually help in any of the places I've ever used .parts.
>
>Paul
>
>PS BTW, did you mean to send to just me rather than the list? I'd like
>to know what other people think of your point.