[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
ncoghlan at gmail.com
Mon Apr 11 02:27:07 EDT 2016
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  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
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).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev