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

[Nick Coghlan]

On 11 April 2016 at 02:16, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 04/09/2016 10:31 PM, Nick Coghlan wrote:
>>
>> On 10 April 2016 at 02:41, Ethan Furman wrote:
>
>
>> When somebody hands you bytes rather than text you need to worry about
>> the encoding, and you need to worry about returning bytes rather than
>> text yourself. https://hg.python.org/cpython/rev/e44410e5928e#l4.1
>> provides an illustration of how fiddly that can get, and that's in the
>> URL context - cross-platform filesystem path handling is worse, since
>> you need to worry about the significant differences between the way
>> Windows and *nix handle binary paths, and you can't use os.sep
>> directly any more (since that's always text).
>
>
> Okay, that makes sense.
>
>> DirEntry can still get the check, it can just throw TypeError when it
>> represents a binary path (that's one of the advantages of using a
>> method-based protocol - exceptions on method calls are more acceptable
>> than exceptions on property access).
>
>
> I guess I don't see the point of this.  Either DirEntry's [1] only get
> partial support (which is only marginally better than the no support pathlib
> currently has), or stdlib code will need to catch those errors and then do
> an isinstance check to see if knows what the type is and how to deal with it
> [1].

What's wrong with only gaining partial support? Standard library code
that doesn't currently support DirEntry at all will gain the ability
to support str-based DirEntry objects, while bytes-based DirEntry
objects will continue to be a low level object that isn't
interoperable with most other APIs (which is fine - anyone writing low
level POSIX-specific code can deal with unpacking the values
explicitly, it just won't happen implicitly anywhere).

Cheers,
Nick.

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