(original) (raw)

On Apr 13 2016, Brett Cannon <brett@python.org> wrote:
\> On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev <
\> python-dev@python.org> wrote:
\>
\>> Ethan Furman 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.