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

[Wes Turner]

On Apr 6, 2016 12:47 PM, "Brett Cannon" <brett at python.org> wrote:
>
>
>
> 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 two methods? __uripath__?

(scheme, host (port), path, query, fragment) so, not __uripath__

what would be the difference between __path__ and __fspath__?

>
>>
>> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
>
>
> See the points about next() vs __next__()

Path(b'123') / u'456'

similarly,
Path(b'123') / UTF8 / UTF16

>
>>
>>    * are there examples of cases where this cannot be?
>
>
> I don't understand what you think "cannot be".

What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is
distinct from what any given programmer chooses to do with their code.

>
>>
>>       * 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.

this seems to be a sudden, arbitrary distinction.

are these proposals necessarily disjoint?

so,
adding getattr(path, '__path__', path) to stdlib and other code is going to
prevent which edge cases (before  os.path.normpath()* anyway) for which
benefit?

when do I do getattr(path, '__fspath__', path)?

>
> -Brett
>
>>
>>          * str.__div__ is nonsensical
>>          * pathlib.Path.__div__ is super-useful

ah, not .__add__() but .append()

I suppose the request here is for the cases which would be prevented (that
we need to learn to look for)

>>
>>
>>
>> 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/101ee9ed/attachment-0001.html>