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

[Nathaniel Smith]

On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 6 April 2016 at 15:57, Serhiy Storchaka <storchaka at gmail.com> wrote:
>> On 06.04.16 05:44, Nick Coghlan wrote:
>>>
>>> The most promising option for that is probably "getattr(path, 'path',
>>> path)", since the "path" attribute is being added to pathlib, and the
>>> given idiom can be readily adopted in Python 2/3 compatible code
>>> (since normal strings and any other object without a "path" attribute
>>> are passed through unchanged). Alternatively, since it's a protocol,
>>> double-underscores on the property name may be appropriate (i.e.
>>> "getattr(path, '__path__', path)")
>>
>> This was already discussed. Current conclusion is using the "path"
>> attribute. See http://bugs.python.org/issue22570 .
>
> 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.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org