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 firstname.lastname@example.org 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)) + ".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?
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/%7Etank/spg-l/sigaction.htm
Jack Jansen wrote:
One problem I see is that what you'd really like is to overload + and split and such on path objects.
Yup. Although it's unclear to me what would be the best behavior for +, because it could mean several things:
1) p = Path(a_directory) + filename # os.path.join(a_directory, filename) 2) p = Path(a_file) + ".ext" # a_file + ".ext"
1) is very useful, but then 2) wouldn't work... So it's not all straightforward.
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...
Yes, that's important to consider, too.
On the other hand: the os.path.* functions could be made aware of the path object, similar to string.py, except it should fall back to the existing code when a string gets passed.