[Python-Dev] When should pathlib stop being provisional?
brett at python.org
Wed Apr 6 13:46:51 EDT 2016
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.
> * 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>
>> 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
>>> 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.
>> Python-Dev mailing list
>> Python-Dev at python.org
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev