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

Koos Zevenhoven k7hoven at gmail.com
Mon Apr 11 07:46:12 EDT 2016

On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

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 textpath = os.fsdecode(bytespath) bytespath = os.fsencode(textpath) # Getting a text path from an arbitrary object textpath = os.fspath(obj) # This doesn't scream "returns text!" to me textpath = os.fspathname(obj) # This does # Getting a binary path from an arbitrary object bytespath = os.fsencode(os.fspath(obj)) bytespath = 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).

Regarding the name, I completely agree with Nick's reasoning (above). I'm not sure it's a high priority to make dunder-method names short. They are not typed very often, and when the number of these "protocols" increases, you face potentially ambiguous names more and more often (there already is a 'path' and a 'file' etc., as has been brought up earlier in these threads.). In other words, it's a good idea to have some information in the name.

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

Or byte strings, it seems, unfortunately.

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

If fspathname(...) is to be used in os.path.*, it will break things if it starts to turn encoded bytes pathnames into str pathnames, which it did not previously do.

And if fspathname is not to be used in os.path.*, who would be our intended user of fspathname? I assume we we don't want to encourage typical 'users' to manipulate pathnames by hand.

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.

+1 to this too.

-Koos

More information about the Python-Dev mailing list