On Mar 31, 2016 10:02 AM, "Paul Moore" p.f.moore@gmail.com wrote:
That's a very interesting perspective, and one I'd not fully appreciated. Thanks for posting it.
There's a lot I still have to think about in your post, but there's one point I'd like to comment on already:
On 31 March 2016 at 15:43, Sven R. Kunze srkunze@mail.de wrote:
When doing so for reading or writing that resource, you actually don't
care
about whether the path consists of parts or not.
While that's true for *existing* resources (files) it's not so true for when you're creating a file. Like it or not, the filesystem imposes a set of container-containee relationships that is the directory structure. Your mental model (the application domain view) may not care about this, but at the "path" level, we're representing the filesystem structure, where directories are real, and so a/b/c being a set of 3 nested objects, 2 directories and a leaf object (which may be a file or itself a directory) is the reality being modeled.
So I'd suggest that your "resource address" is a higher level abstraction, layered on top of the filesystem. In many ways, it's a URI - and as such may map to a filesystem path or to something else. This also clarifies (at least to me) why I am uncomfortable about the idea of merging pathlib and URIs - they are at 2 different abstraction levels.
It's somewhat interesting to me that the "resource address" level of abstraction is a higher level that the "filesystem path" level, but has *less* structure. That seems reasonable to me (you abstract away the details). And it makes the string representation at the "lowest level" the really odd case, as it has *no* structure, and yet it's representing a detail level of object structure. Maybe that's an indication of why it's useful to have a structured Path object at this level rather than working solely with strings?
it would seem that the utility here includes having a @memoize-d parsed copy of the path; and then not doubling forward/backslashes ... and then checking for '../' traversals and any chroot-like relpath predicates w/ e.g. fnmatch); and not shell quoting
None = gethostname() os.path.sep.join(['file:', None, '/home/user/']) os.path.sep.join(['file:', None, ('/home', '/user/')])
p = Path('/home/user/') p.parts
# ... URLObject + path.py
Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/