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].
On the other hand, if __fspath__ is allowed to hold bytes then the
algorithm gets easier:
- get the serialized form
- check for bytes or str and act accordingly
As a practicality argument that seems a lot easier for everybody.
--
~Ethan~
[1] Being a low-level function I think working with either bytes or
str is entirely appropriate for DirEntry.
[2] DirEntry? Oh yeah, grab the .path attribute. Something else?
Bah, let the exception propogate.
_______________________________________________
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
