This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients josh.r, p-ganssle
Date 2021-10-08.19:08:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1633720100.42.0.426447756208.issue45414@roundup.psfhosted.org>
In-reply-to
Content
This is a great bug report, but for anyone else who gets a bit lost in the details, here's the core of the issue:

>>> p = Path("/1/2")
>>> q = Path("1/2")

>>> p.parents[-1]  # This is correct
PosixPath('/')
>>> q.parents[-1]
PosixPath('.')

>>> p.parents[-2]  # Should be PosixPath('/1')
PosixPath('/')
>>> q.parents[-2]
PosixPath('1')

>>> p.parents[-3]  # Should be PosixPath('/1/2')
PosixPath('/1')
>>> q.parents[-3]
PosixPath('1/2')

I think a refactoring where '/' doesn't appear in ._parts would be a good idea if we can get past Chesterton's Fence and determine that this was indeed not a deliberate design decision (or at least one whose concerns no longer apply), but at least in the short term, I agree that transforming negative indexes into positive indices is the right, expedient thing to do.

We'll definitely want to make sure that we're careful about bad indices (and add relevant tests), though, since it would be easy to get weird behavior where too-large negative indexes start "wrapping around" (e.g. p.parents[-4] with len(p._parents) == 3 → p.parents[-1]).
History
Date User Action Args
2021-10-08 19:08:20p-gansslesetrecipients: + p-ganssle, josh.r
2021-10-08 19:08:20p-gansslesetmessageid: <1633720100.42.0.426447756208.issue45414@roundup.psfhosted.org>
2021-10-08 19:08:20p-gansslelinkissue45414 messages
2021-10-08 19:08:20p-gansslecreate