[Python-Dev] When should pathlib stop being provisional?

[Ethan Furman]

On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> On 6 April 2016 at 16:53, Nathaniel Smith <njs at pobox.com> wrote:
>> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

>>> I'd missed the existing precedent in DirEntry.path, so simply taking
>>> that and running with it sounds good to me.
>>
>> This makes me twitch slightly, because NumPy has had a whole set of
>> problems due to the ancient and minimally-considered decision to
>> assume a bunch of ad hoc non-namespaced method names fulfilled some
>> protocol -- like all .sum methods will have a signature that's
>> compatible with numpy's, and if an object has a .log method then
>> surely that computes the logarithm (what else in computing could "log"
>> possibly refer to?), etc. This experience may or may not be relevant,
>> I'm not sure -- sometimes these kinds of twitches are good guides to
>> intuition, and sometimes they are just knee-jerk responses to an old
>> and irrelevant problem :-)
>>
>> But you might want to at least think about
>> how common it might be to have existing objects with unrelated
>> attributes that happen to be called "path", and the bizarro problems
>> that might be caused if someone accidentally passes one of them to a
>> function that expects all .path attributes to be instances of this new
>> protocol.
>
> sys.path, for example.
>
> That's why I'd actually prefer the implicit conversion protocol to be
> the more explicitly named "__fspath__", with suitable "__fspath__ =
> path" assignments added to DirEntry and pathlib. However, I'm also not
> offering to actually *do* the work here, and the casting vote goes to
> the folks pursuing the implementation effort.

If we decide upon __fspath__ (or __path__) I will do the work on pathlib 
and scandir to add those attributes.

--
~Ethan~