<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 13 Apr 2016 at 09:52 Random832 <<a href="mailto:random832@fastmail.com">random832@fastmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote:<br>
> On 04/13/2016 08:17 AM, Random832 wrote:<br>
> > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote:<br>
><br>
> >> I'd expect the main consumers to be os and os.path, and would honestly<br>
> >> be surprised if we needed many explicit invocations above that layer,<br>
> >> other than in pathlib itself.<br>
> ><br>
> > I made a toy implementation to try this out, and making os.open support<br>
> > it does not get you builtin open "for free" as I had suspected; builtin<br>
> > open has its own type checks in _iomodule.c.<br>
><br>
> Yup, it will take some effort to make this work.<br>
<br>
A corner case just occurred to me...<br>
<br>
For functions that will continue to accept str/bytes (and functions that<br>
accept some other type such as Number or file-like objects), what should<br>
be done with an object that is one of these, *and* has an __fspath__<br>
method, *and* this method returns a value other than the object's own<br>
value? Basically, should the protocol check be done unconditionally<br>
(before attempting to use the argument as a string) or only if the<br>
argument is not a string (there's an efficiency argument for this). Or<br>
should it be left "unspecified", with the understanding that such<br>
objects are badly behaved and may not be handled consistently across<br>
different functions / python implementations / cpython versions?<br>
<br>
Also, should the os.fspath (or whatever we call it) function itself<br>
accept str/bytes, even if these are not going to implement the protocol?<br></blockquote><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">All of this is demonstrated in </span><a href="https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1">https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1</a> 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 :) .</div></div></div>