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

[Wes Turner]

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

* why not Text(basestring / bytestring) and pathlib.Path(Text)?
   * are there examples of cases where this 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?
         * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/ede89530/attachment.html>