On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath <nikol...@rath.org> wrote:
> On Apr 13 2016, Brett Cannon <br...@python.org> wrote: > > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > > python-dev@python.org> wrote: > > > >> Ethan Furman <ethan <at> 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 _allow_bytes=GLOBAL_CONFIG_OPTION 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 > > allow_bytes 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.
_______________________________________________ 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
