[Python-Dev] file system path protocol PEP

[Steven D'Aprano]

On Thu, May 12, 2016 at 07:22:25PM +0200, Sjoerd Job Postmus wrote:

> The whole point of adding `os.fspath` is to make it easier to use Path
> objects. This is in an effort to gain greater adoption of pathlib in
> libraries. Now, this is an excellent idea.
> 
> However, if it were to reject bytes, that would mean that when libraries
> start to use pathlib, it would suddenly become harder for people that
> actually need bytes-support to use pathlib.

I'm not sure how it would be *harder*. Currently, if you need bytes 
paths, you can't use pathlib. That won't change, so it will be exactly 
as hard as it is now.


> Now, the claim 'if you need bytes, you should not be using pathlib` is a
> reasonable one. But what if I need bytes *and* a specific library (say,
> image handling, or a web framework, or ...). It's not up to me if that
> library uses pathlib or plain old os.path.join.

I feel this is Not Our Problem. Surely the stdlib cannot be held 
responsible for all the poor decisions made by third-party libraries? If 
a library hard-codes "\\" as their directory separator, because everyone 
uses Windows, you'd simply say "this library is not very good for my 
use-case". Likewise if it rejects bytes paths, then:

- perhaps that library is not fit for your purpose;

- perhaps you can use it, but with the limitation that you can no 
  longer support all paths, but only the ones which can be 
  accessed via a string path;

- perhaps you can build a compatibility layer that lets you use 
  both bytes and the library.

I don't doubt that all three options are unpleasant, but I don't see how 
they are the fault of this PEP. This PEP supports Path-Like objects that 
return bytes paths. Its up to library authors to support bytes paths, or 
not, as they see fit.



-- 
Steve