On 11 April 2016 at 02:16, Ethan Furman <et...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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