[Python-ideas] URLs/URIs + pathlib.Path + literal syntax = ?

[Chris Angelico]

On Wed, Mar 30, 2016 at 6:42 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Chris Angelico writes:
>  > On Wed, Mar 30, 2016 at 3:06 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>
>  > > This means that URIs can be canonicalized syntactically, while doing
>  > > so with file system paths is risky.
>  >
>  > Or there are two operations: canonicalizing by components, and
>  > rendering a "true path", which requires file system access (stat every
>  > component).
>
> That's not to my taste because while you do need to make that choice
> for filesystem paths, it's always safe (in the sense of "you're buggy,
> not me!") to canonicalize a URI.

Yes, this is true; for a non-file-system URI, the "true path" would
simply be identical to the component-based canonicalization.

> Also, RFC 3896 explicitly refuses to require URIs to make any physical
> sense, while it's an error for a filesystem path to refer to a
> non-existent object.  In other words, URIs are abstract syntax to
> which you can assign whatever semantics you want (as long as they are
> compatible with the syntax), while filesystem paths are actual paths
> in a graph that is instantiated in hardware storage.

Hmm. Not sure what you mean by that error - how else could you create
a new file, than by identifying a path that does not exist? You're
absolutely right that URIs have no specific physical meaning, yet they
do have definite semantic meaning; an HTTP client can (and should)
resolve relative URLs itself, rather than simply sticking
"../../static/main.css" on the end of the current URL.

> I suspect you won't have a problem with that distinction, but ISTM
> that it's the exact opposite of the way the "let's derive Path from
> str" (or from "BaseString" or whatever) crowd want to think
> (filesystem paths are a subset of strings).
>

Even if a file system path is a special form of string, this will
work. It's just that the semantics would have to be defined sans
canonicalization, with two methods that do that.

But I am liking the line of thinking (not posted in this exact thread,
so I'm not sure who said it - sorry!) that Paths are as abstract as
integers and text strings, and that they should have no particular tie
to their mechanical implementation. The string "/home/rosuav/foo.py"
should be more like a "path display" (by analogy with lists etc) than
an actual Path.

ChrisA