Repository navigation
Make Path subscriptable #139270
Description
Activity
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Sep 23, 2025 - addedstdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory
on Sep 23, 2025 To be explicit, the workarounds are:
In [1]: x = Path("hello/there/general/kenobi") In [2]: x.parents[1] Out[2]: PosixPath('hello/there') In [3]: Path(*x.parts[0:2]) Out[3]: PosixPath('hello/there')
Adding subscripting might be useful, but it also could be adding entropy.
Several of the current methods/accessors (e.g,.
name,root) return a string instead of Path.Not sure if encouraging different access patterns, such as
x[-1]instead ofx.namebased on the expected return of astrorPathis a good idea.For example, with
x = Path("/a/b/c.txt"usingx.root(returns str) instead ofx[0](returns Path). Similarly,x.nameinstead ofx[-1] -> Path("c.txt")with__getitem__mechanics.For example:
In [1]: from pathlib import Path In [2]: p = Path("/a/b/c.txt") In [3]: p.root Out[3]: '/' In [4]: p.name Out[4]: 'c.txt' In [5]: # p[0] -> PosixPath("/") In [6]: # p[-1] -> PosixPath("c.txt") In [8]: p.parents[-1] Out[8]: PosixPath('/')
Interesting feature request idea, but the workaround
Path(*x.parts[0:3]))is pretty straightforward.Reacted by Barney Gale and sobolevnFor me this looks a bit too magical. I would not want to associtate numbers with path components. For example:
x = Path('/a')andx = Path('C:\\a'). What wouldx[0]be in these cases?Further more, it is also not really clear from the code that
Path('a/b')[0]returnsPath('a')because it is also kinda expected to return'a', because of'a/b'[0]expectations.I don't see a big problem in using
Path(*Path('a/b').parts[0:1]), it is clear, short and fast.Reacted by Sergey Miryanov, yihong, W. H. Wang, Bénédikt Tran and Barney GaleI'm also -1. I'm going to close this as
not planned. In the future, please consider opening a thread on https://discuss.python.org/c/ideas/6 first.Reacted by Barney GaleSeveral of the current methods/accessors (e.g,.
name,root) return a string instead of Path.To expand on this a bit:
pathlib usually treats relative paths as relative to the current directory, not just free-floating partial paths. If my working directory is
/home/barneyand I havep = Path('.local/share'), any operations I perform onpshould only generatePathobjects that also make sense relative to the same working directory. Sop.parentgenerates aPathobject becausePath('.local')still makes sense, butp.namegenerates astrbecausePath('share')wouldn't. There are exceptions, e.g.p.relative_to().Allowing arbitrary slices that generate
Paths would break this rule. It would be fine if we insisted that slices start at0, but at that point you may as well usepath.parents.There's maybe an argument for a
path.lineageattribute that works likepath.parentsbut in reverse and includingselfat the end. So in my previous example,p.lineage == (Path(), Path('.local'), Path('.local/share')). But that's for the forum if someone wants to pursue it :)
Feature or enhancement
Proposal:
Pathshould be subscriptable so I can select components, e.g.(This is a more convenient alternative to
.parts, which returns a tuple of strings I have to reassemble into a path.)Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
No response