[Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings?
Markus Unterwaditzer
markus at unterwaditzer.net
Tue Mar 24 13:39:55 CET 2015
Forgot to reply to list!
-------- Original Message --------
From: Markus Unterwaditzer <markus at unterwaditzer.net>
Sent: 24 March 2015 13:25:27 CET
To: Paul Moore <p.f.moore at gmail.com>
Subject: Re: [Python-ideas] pathlib.Path.parts - tuple of path objects rather than strings?
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.
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.
But I'm not sure where you'd use that.
-- Markus
On 24 March 2015 13:08:25 CET, Paul Moore <p.f.moore at gmail.com> wrote:
>One occasional problem I have with pathlib.Path.parts is that it
>returns a tuple of strings. For WindowsPath objects, paths are case
>insensitive but strings aren't. So we get the situation that
>
>>>> p1 = pathlib.PureWindowsPath('foo')
>>>> p2 = pathlib.PureWindowsPath('FOO')
>>>> p1 == p2
>True
>>>> p1.parts == p2.parts
>False
>
>Making p1.parts return a tuple of objects of type p1.__class__ would
>address this:
>
>>>> [p1.__class__(p) for p in p1.parts] == [p2.__class__(p) for p in
>p2.parts]
>True
>
>Is this something that's worth changing (pathlib is still provisional,
>so the backward compatibility break would technically be allowed, even
>if it's not ideal)? Or would an extra property, say p.path_parts that
>returned a tuple of path objects be worth considering?
>
>As it is, use of path.parts is a potential source of portability bugs,
>where Unix users don't consider the case sensitivity issue. (Heck, as
>a Windows user, I almost missed the problem in my implementation of
>common_prefix, so it's not just Unix users...)
>
>Paul
>_______________________________________________
>Python-ideas mailing list
>Python-ideas at python.org
>https://mail.python.org/mailman/listinfo/python-ideas
>Code of Conduct: http://python.org/psf/codeofconduct/
More information about the Python-ideas
mailing list