[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

[Ethan Furman]

On 04/11/2016 09:32 AM, Zachary Ware wrote:
> On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote:

>> If those examples are anywhere close to accurate, an fspath protocol that
>> supported both bytes and str seems a lot easier to work with.
>
> But why are you working with bytes paths in the first place? Where did
> you get them from, and why couldn't you decode them at that boundary?
> In 7ish years of working with Python (almost exclusively Python 3) on
> Windows and UNIX, I have never used bytes paths on any platform.

I'm not saying that bytes paths are common -- and if this was a 
brand-new feature I wouldn't be pushing for it so hard;  however, bytes 
paths are already supported and it seems to me to be much less of a 
headache to continue the support in this new protocol instead of drawing 
an artificial line in the sand.

Also, let me be clear that the new protocol will not adversely affect my 
own library is it directly subclasses bytes and strings (bPath and 
uPath), so they will pass through either way (or be appropriately 
rejected if the function only supports str -- are there any?) .

This kind of feels like PEP 361 again -- the vast majority of Python 
programmers do not need %-interpolation for bytes, but what a pain in 
the rear for those that did!  (Yes, I was one of those.)  Admittedly, 
the pain from this will not be nearly as severe as that was, but why 
should we have any unnecessary pain at all?

Asked another way, what are we gaining by disallowing bytes in this new 
way of getting paths versus the pain caused when bytes are needed and/or 
accepted?

 From my point of view the pain of simply implementing this without 
bytes support in the existing os and os.path modules is not worth 
excluding bytes.

--
~Ethan~