[Python-Dev] file system path protocol PEP

[Nick Coghlan]

On 12 May 2016 at 22:40, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Thu, May 12, 2016 at 3:04 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> I'd still like to see this exposed to Python code as os._raw_fspath()
>> (with the leading underscore just meaning "this probably isn't the API
>> you want" rather than indicating a private or unstable API), and then
>> fspath() defined as a wrapper around it which disallows bytes as
>> output.
>
> I don't remember (should probably check) if you previously proposed
> implementing exactly that in C, but I indeed agree with what you write
> above, except that I don't like the "_raw_" prefix in the name. I
> would be willing to call that simply fspath though, since as mentioned
> before in this thread (I think by Brett and me), the reasons for
> rejecting bytes in fspath are really quite minor.

It's not unusual for me to encounter "POSIX oughtta be enough for
anyone" folks that are not yet entirely convinced that
bytes-are-not-text, so I'm actually in favour of making the default
Python-level API str-only as a healthy nudge away from the
"text-is-just-bytes-with-an-encoding!" school of thought.

However, in terms of the three groups Brett articulated (maximum
flexibility, encouraging cross-platform correctness, and forgetting
the whole idea), I'm in both camps 1 & 2 - I work with POSIX enough
that I'm entirely on board with the notion that if you're specifically
modelling *POSIX* paths, then bytes-with-an-assumed-encoding is
frequently a good enough representation, but also deal with other
environments (like Windows, the JVM and the CLR) enough to know that
that particular representation of filesystem paths breaks down the
moment you expand your scope of interest beyond *nix platforms.

Hence the suggestion of having os.fspath() be the group 2
guaranteed-to-only-emit-str API, with os._raw_fspath() as the lower
level "I know I'm potentially being POSIX-centric here, but that's OK
for my use case" group 1 interface.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia