On 12 May 2016 at 22:40, Koos Zevenhoven <k7ho...@gmail.com> wrote: > On Thu, May 12, 2016 at 3:04 PM, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
