On 9 April 2016 at 04:25, Brett Cannon <br...@python.org> wrote:
> On Fri, 8 Apr 2016 at 11:13 Ethan Furman <et...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
