Eric Snow writes: > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon <br...@python.org> wrote: > > Ah, but you see that doesn't make porting easy.
> Perhaps I missed previous discussion on the point, but why not support > both __fspath__() -> str and __fssyspath__() -> bytes? That's fine by me, I can live with that although I don't really like it. But the proponents of polymorphic __fspath__ think it's unnecessary. Why I don't like it: what's going to end up happening is that a __fspath__- or __fssyspath__-bearing object of unknown provenance is going to get passed to polymorphic os functions that won't complain, and a few million cycles later something is going to access fileobj.path expecting bytes and getting str, and blooey! Also I just don't see a need for bytes when the original purpose of this was to support passing pathlib.Path objects to open. It's also nice to pass DirEntry objects to open, but it's not obvious to me that we need to support bytes since only new code can use this feature, and there's a way to not-support them that doesn't cause any new problems. It's not that I want bytes to go away[1], it's just that the playing field will tilt a little more against them in new code. Footnotes: [1] I wouldn't weep, but I wouldn't laugh, either. _______________________________________________ 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
