[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()
Stephen J. Turnbull
stephen at xemacs.org
Tue Apr 19 07:46:38 EDT 2016
Brett Cannon writes:
> On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Well, it makes *your* head hurt;
It doesn't, because I have a different (and IMHO better) model. I can
interpret yours without pain by comparing to that.
> By providing os.fspath() I can say that I do not, under any
> circumstances, want someone to guess at the encoding some bytes
> path is under to get me a string and instead I want to start and
> end entirely in a world of strings. IOW os.fspath() lets me work in
> such a way that the instant bytes are introduced into my code for
> file paths it triggers a TypeError.
Does it really help you work that way? open is polymorphic, and will
use os._raw_fspath(obj, (bytes,str)). Ditto os.scandir etc. If they
don't, there's no point in supporting bytes returns from __fspath__,
is there? Application code will normally not be calling os.fspath.
In the future, pathlib will, I suppose, but even without os.fspath
pathlib already protects you, as does antipathy.
More effective, then, is just to use pathlib for your Path-hacking
work as soon as the path-representing object appears, and Path will
complain about bytes for you. This is an analogue of the "decode
bytes at the boundary" principle.
> Yep, we are stuck with the names unless you want to propose a new
> name and deprecate the old one.
I already proposed fs_ensure_bytes and fs_ensure_str. I think they're
sufficiently ugly to prove my point.<wink/>
 Strictly speaking, antipathy protects you from inadvertant mixing
of bytes and str.
More information about the Python-Dev