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.[1] 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/> Footnotes: [1] Strictly speaking, antipathy protects you from inadvertant mixing of bytes and str.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4