[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for fspath and os.fspath() (original) (raw)

Random832 random832 at fastmail.com
Thu Apr 14 08:28:29 EDT 2016

On Thu, Apr 14, 2016, at 02:00, Nick Coghlan wrote:

> If the protocol can return bytes, then that means that types (DirEntry? > someone had an alternate path library with a bPath?) which return bytes > via the protocol will proliferate, and cannot be safely passed to > anything that uses os.fspath. Numerous copies of "def myfspath(x): > return os.fsdecode(os.rawfspath(x))" will proliferate (or they'll just > monkey-patch os.fspath), and no-one actually uses os.fspath except toy > examples.

If folks want coercion, they can just use os.fsdecode(x), as that already has a str -> str passthrough from the input to the output (unlike codecs.decode) and will presumably be updated to include an implicit call to os.rawfspath() on the passed in object.

This is the first I've heard of any suggestion to have fsdecode accept non-strings.

> Why is it so objectionable for os.fspath to do coercion?

The first problem is that binary paths on Windows basically don't work, so it's preferable for them to fail fast regardless of platform, rather than to have them implicitly work on *nix, only to fail for Windows users using non-ASCII paths later.

Ideally, this warning would be raised from a central place, and even fspath (and even fsdecode) would go through it.

More information about the Python-Dev mailing list