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
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