On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > 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). >
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 _______________________________________________ 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