[Python-Dev] pathlib - current status of discussions (original) (raw)

Brett Cannon brett at python.org
Wed Apr 13 19:06:35 EDT 2016

On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath <Nikolaus at rath.org> wrote:

On Apr 13 2016, Brett Cannon <brett at python.org> wrote: > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev <_ _> python-dev at python.org> wrote: > >> Ethan Furman <ethan stoneleaf.us> writes: >> >> > Do we allow bytes to be returned from os.fspath()? If yes, then do we >> > allow bytes from fspath()? >> >> De-lurking. Especially since the ultimate goal is better interoperability, >> I >> feel like an implementation that people can play with would help guide the >> few remaining decisions. To help test the various options you could >> temporarily add a allowbytes=GLOBALCONFIGOPTION default argument to >> both >> pathlib.fspath() and os.fspath(), with distinct configurable defaults >> for >> each. >> >> In the spirit of Python 3 I feel like bytes might not be needed in >> practice, >> but something like this with defaults of False will allow people to easily >> test all the various options. >> > > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has > the four potential approaches implemented (although it doesn't follow the > "separate functions" approach some are proposing and instead goes with the > allowbytes approach I originally proposed).

When passing an object that is of type str and has a fspath attribute, all approaches return the value of fspath(). However, when passing something of type bytes, the second approach returns the object, while the third returns the value of fspath(). Is this intentional? I think a fspath attribute should always be preferred.

It's very much intentional. If we define fspath() to only return strings but still want to minimize boilerplate of allowing bytes to simply pass through without checking a path argument to see if it is bytes then approach #2 is warranted. But if fspath() can return bytes then approach #3 allows for it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160413/10deaf2e/attachment.html>

More information about the Python-Dev mailing list