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

[Wes Turner]

On Mar 31, 2016 10:36 AM, "Wes Turner" <wes.turner at gmail.com> wrote:
>
>
> 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

URLObject has a .path attr for getattr, too.

- char*: bytestring, unicode/str

>
> >
> > 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/f2775e6a/attachment-0001.html>