> Every once in a while I wished for an path object to manipulate file > system paths. Things like > os.path.join(a, b, c, os.path.splitext(os.path.basename(p))[0] + ".ext") > quickly get frustrating (so of course I never write them like that ;-). > > I thought of implementing a path object several times, but always > stopped when I realized (for the Nth time ;-) that you'd then have > to do something like > file = open(p.tostring()) > whenever you want to *use* your pat. That doesn't help at all. Two better solutions: (1) If the Path class defines a __str__() method, you can write open(p). (2) You could add an open method to the Path class, and write p.open(). > But: since strings are now subclassable (there are, aren't they?) > this should no longer be a problem! > > Would it be a worthwile project to design and implement a path > object for the standard library? I'm lukewarm on adding this to the std library. Java has such a thing and I never warmed up to it. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4