<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 18 April 2016 at 07:05, Koos Zevenhoven <span dir="ltr"><<a href="mailto:k7hoven@gmail.com" target="_blank">k7hoven@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>
> On 04/17/2016 06:58 AM, Koos Zevenhoven wrote:<br>
><br>
>> So, as a summary: With a str+bytes-polymorphic __fspath__, with the<br>
>> above argumentation and the rough implementation of os.fspath(...),<br>
>> the conclusion is that the os.fspath function should indeed be public,<br>
>> and that no further variations are needed.<br>
><br>
><br>
> Nice summation, thank you.  :)<br>
><br>
<br>
</span>Come on, Ethan, that summary was not for you ;)</blockquote><div><br></div><div>As Chris noted though, the "Yes, that summary is accurate" from active participants in the discussion helps assure readers that it's a good overview :)<br><br></div><div>Given the variant you suggested, what if we defined the API semantics like this:<br><br></div><div>    # Offer the simplest possible API as the public vesion<br></div><div>    def fspath(pathlike) -> str: <br></div><div>        return os._raw_fspath(pathlike)<br></div><div><br></div><div>    # Expose the complexity in the "private" variant<br></div><div>    def _raw_fspath(pathlike, *, output_types = (str,)) -> (str, bytes):<br></div><div>        # Short-circuit for instances of the output type<br></div><div>        if isinstance(pathlike, output_types):<br></div><div>            return pathlike<br></div><div>        # We'd have a tidier error message here for non-path objects<br></div><div>        result = pathlike.__fspath__()<br>        if not isinstance(result, output_types):<br>            raise TypeError("argument is not and does not provide an acceptable pathname")<br>        return result<br></div><div><br></div></div>That way, the default API would be saying unambiguously that the preferred way of manipulating filesystem paths is as text, but the lower level "mainly for the standard library" API would explicitly handle the 3 different scenarios (binary-input-is-a-bug, text-input-is-a-bug, and either-binary-or-text-input-is-fine).<br><br></div><div class="gmail_extra">That way the structure of the additional parameters on _raw_fspath can be tailored specifically to the needs of the standard library, without worrying as much about 3rd party use cases.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>