One problem I see is that what you'd really like is to overload + and split and such on path objects. But this creates a problem if you then pass this path object to something that expects old-fashioned strings: if it wants to manipulate that path it will use string operations, which suddenly have different semantics... Recently, Just van Rossum <just@letterror.com> said: > 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 whe > n 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. > > 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? > > Just > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm
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