[Python-Dev] Pathlib enhancments - method name only (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Apr 9 03:48:38 EDT 2016

On 9 April 2016 at 04:25, Brett Cannon <brett at python.org> wrote:

On Fri, 8 Apr 2016 at 11:13 Ethan Furman <ethan at stoneleaf.us> wrote:

On 04/08/2016 10:46 AM, Koos Zevenhoven wrote: > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: >> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:

>>> I'm still thinking a little bit about 'pathname', which to me sounds >>> more like a string than fspath does. >> >> >> I like that a lot - or even "pathstr" or "pathstring" >> after all, we're making a big deal out of the fact that a path is >> not a string, but rather a string is a representation (or >> serialization) of a path. That's a decent point. So the plausible choices are, I think: - fspath # File System Path -- possible confusion with Path +1

I like fspath, but I'm also sympathetic to Koos' point that we're really dealing with path names being produced via this protocol, rather than the paths themselves.

That would bring the completely explicit "fspathname" into the mix, which would be comparable in length to "getattribute" as a magic method name (both in terms of number of syllable and number of characters).

Considering the helper function usage, here's some examples in combination with os.fsencode and os.fsdecode:

# Status quo for binary/text path conversions
text_path = os.fsdecode(bytes_path)
bytes_path = os.fsencode(text_path)

# Getting a text path from an arbitrary object
text_path = os.fspath(obj) # This doesn't scream "returns text!" to me
text_path = os.fspathname(obj) # This does

# Getting a binary path from an arbitrary object
bytes_path = os.fsencode(os.fspath(obj))
bytes_path = os.fsencode(os.fspathname(obj))

I'm starting to think the semantic nudge from the "name" suffix when reading the code is worth the extra four characters when writing it (keeping in mind that the whole point of this exercise is that most folks won't be writing explicit conversions - the stdlib will handle it on their behalf).

I also think the more explicit name helps answer some of the type signature questions that have arisen:

  1. Does os.fspathname return rich Path objects? No, it returns names as str objects
  2. Will file descriptors pass through os.fspathname? No, as they're not names, they're numeric descriptors.
  3. Will bytes-like objects pass through os.fspathname? No, as they're not names, they're encodings of names

When the name is instead "os.fspath", the appropriate answers to those three questions are far more debatable.

I personally still like ospath as well.

That one fails the "Is it ambiguous when spoken aloud?" test for me: if someone mentions "oh-ess-path", are they talking about os.path or ospath? With "eff-ess-path" or "eff-ess-path-name", that problem doesn't arise.

Cheers, Nick.

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

More information about the Python-Dev mailing list