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

[Wes Turner]

On Mar 31, 2016 10:02 AM, "Paul Moore" <p.f.moore at 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 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?

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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160331/d4796cac/attachment.html>