On 20 April 2016 at 13:16, Stephen J. Turnbull <step...@xemacs.org> wrote:
> What's left is DirEntry (and perhaps other producers of byte-oriented > objects in os and os.path). If they're currently using DirEntry, > they're currently accessing .path. Surely bytes users can continue > doing that, even if we offer str users the advantage of new protocols? > The consuming functions aren't currently allowing DirEntry objects either (since scandir is even newer than pathlib), so we want to allow both pathlib and DirEntry objects with a single change to consuming functions. I'd like to see that change in consuming functions be as simple as possible: an unconditional "path = os._raw_fspath(path)" at the start of their existing input processing Those consuming functions fall into one of three categories: 1. They're bytes/str polymorphic 2. They're bytes only 3. They're str only Whichever category they're in, their existing argument processing will be readily able to cope with a polymorphic result from os._raw_fspath, since that's no different from today, where the argument passed in may be bytes or str and they need to handle that appropriately. Having os.fspath(path) as a specifically str-only layer then gives consuming functions in category 3 an alternative option, and encourages category 3 functions and APIs (like pathlib) as the future default, without getting in the way of the folks that need to mess about down in the low level weeds of operating system interfaces. 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
