(original) (raw)

On 18 April 2016 at 07:05, Koos Zevenhoven <k7hoven@gmail.com> wrote:
On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
\> On 04/17/2016 06:58 AM, Koos Zevenhoven wrote:
\>
\>> So, as a summary: With a str+bytes-polymorphic \_\_fspath\_\_, with the
\>> above argumentation and the rough implementation of os.fspath(...),
\>> the conclusion is that the os.fspath function should indeed be public,
\>> and that no further variations are needed.
\>
\>
\> Nice summation, thank you. :)
\>

Come on, Ethan, that summary was not for you ;)

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 :)

Given the variant you suggested, what if we defined the API semantics like this:

# Offer the simplest possible API as the public vesion
def fspath(pathlike) -> str:
return os.\_raw\_fspath(pathlike)

# Expose the complexity in the "private" variant
def \_raw\_fspath(pathlike, \*, output\_types = (str,)) -> (str, bytes):
# Short-circuit for instances of the output type
if isinstance(pathlike, output\_types):
return pathlike
# We'd have a tidier error message here for non-path objects
result = pathlike.\_\_fspath\_\_()
if not isinstance(result, output\_types):
raise TypeError("argument is not and does not provide an acceptable pathname")
return result

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).

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.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia