[Python-ideas] Working with Path objects: p-strings?

[Paul Moore]

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

Paul