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

[Brett Cannon]

On Wed, 6 Apr 2016 at 10:41 Wes Turner <wes.turner at gmail.com> wrote:

> * +1 for __path__, __fspath__
>   (though I don't know what each does)
>

Returns a string representing a file system path.


> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
>

See the points about next() vs __next__()


>    * are there examples of cases where this cannot be?
>

I don't understand what you think "cannot be".


>       * if not, +1 for subclassing str/Text
>
>       * where are the examples of method collisions between the str
> interface and the pathlib.Path interface?
>

There aren't any and that's partially why some people wanted the str
subclass to begin with.

Please consider this thread a str-subclass-free zone. This line of
discussion is to flesh out the proposal for a path protocol as a proposal
against subclassing str, not to settle the whole discussion outright. If
you want to continue to debate the subclassing-str side of this please use
the other thread.

-Brett


>          * str.__div__ is nonsensical
>          * pathlib.Path.__div__ is super-useful
>
>
> On Apr 6, 2016 10:10 AM, "Ethan Furman" <ethan at stoneleaf.us> wrote:
>
>> 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~
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/9e7c16d5/attachment-0001.html>