[Python-Dev] Pathlib enhancements - acceptable inputs and outputs for fspath and os.fspath() (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Apr 20 02:31:33 EDT 2016

Eric Snow writes:

On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon <brett at 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.

More information about the Python-Dev mailing list