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._raw_fspath(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._raw_fspath() 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. _______________________________________________ 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
