[Python-Dev] pathlib - current status of discussions (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon Apr 11 23:45:00 EDT 2016
- Previous message (by thread): [Python-Dev] pathlib - current status of discussions
- Next message (by thread): [Python-Dev] pathlib - current status of discussions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12 April 2016 at 07:58, Ethan Furman <ethan at stoneleaf.us> wrote:
Sticking points: ---------------
Do we allow bytes to be returned from os.fspath()? If yes, then do we allow bytes from fspath()?
I've come around to the point of view that allowing both str and bytes-like objects to pass through unchanged makes sense, with the rationale being the one someone mentioned regarding ease-of-use in os.path.
Consider os.path.join: with a permissive os.fspath, the necessary update should just be to introduce "map(os.fspath, args)" (or its C equivalent), and then continue with the existing bytes vs str handling logic.
Functions consuming os.fspath can then decide on a case-by-case basis how they want to handle binary paths: either use them as is (which will usually work on mostly-ASCII systems), convert them to text with os.fsdecode (which will usually work on *nix systems), or disallow them entirely (which would probably only be appropriate for libraries that wanted to ensure support for non-ASCII paths on Windows systems).
That then cascades into the other open questions mentioned:
- permitted return types for both fspath and fspath would be (str, bytes)
- the names would be fspath and fspath, since the result may be either a path name as text, or an encoded path name as bytes
Cheers, Nick.
-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
- Previous message (by thread): [Python-Dev] pathlib - current status of discussions
- Next message (by thread): [Python-Dev] pathlib - current status of discussions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]