Forgot to reply to list!
-------- Original Message -------- From: Markus Unterwaditzer email@example.com Sent: 24 March 2015 13:25:27 CET To: Paul Moore firstname.lastname@example.org 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.
On 24 March 2015 13:08:25 CET, Paul Moore email@example.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
p1.parts == p2.parts
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
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 Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/