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

[Petr Viktorin]

On 04/06/2016 08:53 AM, Nathaniel Smith wrote:
> 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
> 

Python was in a similar situation with the .next method on iterators,
which changed to __next__ in Python 3. PEP 3114 (which explains this
change) says:

> Code that nowhere contains an explicit call to a next method can
> nonetheless be silently affected by the presence of such
> a method. Therefore, this PEP proposes that iterators should have
> a __next__ method instead of a next method (with no change in
> semantics).

How well does that apply to path/__path__?

That PEP also introduced the next() builtin. This suggests that a
protocol with __path__/__fspath__ would need a corresponding
path()/fspath() builtin.