On 31.03.2016 17:02, Paul Moore wrote:
That's a very interesting perspective, and one I'd not fully appreciated. Thanks for posting it.
You're welcome.
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?
That all makes perfect sense now.
I didn't expect such a quick and enlightening response. That's awesome. Thanks a lot.
That might also influence how we look at the other thread about including better URL handling to Python. It's just another abstraction level and the main question is: is Python ready for that level or better use a third party library for it.
Best, Sven