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

[Brett Cannon]

On Wed, 13 Apr 2016 at 09:52 Random832 <random832 at fastmail.com> wrote:

> On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote:
> > On 04/13/2016 08:17 AM, Random832 wrote:
> > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote:
> >
> > >> I'd expect the main consumers to be os and os.path, and would honestly
> > >> be surprised if we needed many explicit invocations above that layer,
> > >> other than in pathlib itself.
> > >
> > > I made a toy implementation to try this out, and making os.open support
> > > it does not get you builtin open "for free" as I had suspected; builtin
> > > open has its own type checks in _iomodule.c.
> >
> > Yup, it will take some effort to make this work.
>
> A corner case just occurred to me...
>
> For functions that will continue to accept str/bytes (and functions that
> accept some other type such as Number or file-like objects), what should
> be done with an object that is one of these, *and* has an __fspath__
> method, *and* this method returns a value other than the object's own
> value? Basically, should the protocol check be done unconditionally
> (before attempting to use the argument as a string) or only if the
> argument is not a string (there's an efficiency argument for this). Or
> should it be left "unspecified", with the understanding that such
> objects are badly behaved and may not be handled consistently across
> different functions / python implementations / cpython versions?
>
> Also, should the os.fspath (or whatever we call it) function itself
> accept str/bytes, even if these are not going to implement the protocol?
>

All of this is demonstrated in
https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 by the
various possibilities. In the end it's not a corner case because the
definition of __fspath__ will be such that there's no ambiguity in what
os.fspath() will accept and what __fspath__ can return and the code will be
written to conform to what the PEP dictates (IOW I'm aware that this needs
to be considered in the implementation :) .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160413/9ab9ac2f/attachment.html>