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

Paul Moore p.f.moore at gmail.com
Wed Mar 30 06:49:35 EDT 2016


On 30 March 2016 at 11:07, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Mar 30, 2016 at 6:55 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> On 30 March 2016 at 05:23, Chris Angelico <rosuav at gmail.com> wrote:
>>>> 4)  Path("file:///http://www.example.com")
>>>
>>> Oops, my bad - I forgot about the third slash. It comes to the same
>>> thing, though; for most paths, you can deduce that a prefix "http://"
>>> implies that it's not a file path, and for the rare case when you do
>>> mean that, you can explicitly adorn it.
>>
>> I presume you're deliberately ignoring the fact that most paths come
>> from variables, not from literals, and many come from user input
>> (sometimes even unintended user input such as a "*" expanded by the
>> shell)? It's easy enough to rewrite literals to be unambiguous, but in
>> order to do so for arbitrary input you need to basically implement
>> (part of) a URI parser...
>
> Not quite; what I'm saying is that *any* file path can be made
> unambiguous by prepending "file:///", thus guaranteeing that it will
> be parsed correctly. I'm not sure that this is necessarily a good
> thing, but it's in response to the objection that a magic prefix
> "http://" would introduce an impossibility.

I don't know if that's true for Windows paths. You'd need to switch
backslashes to slashes, for a start (and *not* do that on Unix, where
backslash is a valid filename character, albeit a silly one to use).
And the URL syntax for drive letters is at best inconsistent across
applications, and at worst undefined (I don't know if the standards
define it, but if they do, I do know that not all applications follow
the same rules).

Paul


More information about the Python-ideas mailing list