Brett Cannon writes: > On 2016年4月18日 at 12:26 Stephen J. Turnbull <[email protected]> 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. _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com