Forgot to reply to list!
-------- Original Message -------- From: Markus Unterwaditzer markus@unterwaditzer.net Sent: 24 March 2015 13:25:27 CET To: Paul Moore p.f.moore@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@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/