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/')

# ... 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/