[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

Ryan Gonzalez rymg19 at gmail.com
Wed Apr 6 15:29:51 EDT 2016

[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
On Apr 6, 2016 12:28 PM, "Brett Cannon" <brett at python.org> wrote:
> WIth Ethan volunteering to do the work to help make a path protocol a
thing -- and I'm willing to help along with propagating this through the
stdlib where I think Serhiy might be interested in helping as well -- and a
seeming consensus this is a good idea, it seems like this proposal has a
chance of actually coming to fruition.
> Now we need clear details. :) Some open questions are:

My votes:

> Name: __path__, __fspath__, or something else?

__path__. Considering everything related to `pathlib` uses the word `path`,
__fspath__ seems kind of odd.

> Method or attribute? (changes what kind of one-liner you might use in
libraries, but I think historically all protocols have been methods and the
serialized string representation might be costly to build)

Method. Using an attribute would be needlessly inconsistent.

> Built-in? (name is dependent on #1 if we add one)
> Add the method/attribute to str? (I assume so, much like __index__() is
on int, but I have not seen it explicitly stated so I would rather clarify

I agree; this would avoid lots of excess complexity.

> Expand the C API to have something like PyObject_Path()?

-1. PyFileObject was already removed from Python 3; it seems useless to add
another one.

> Some people have asked for the pathlib PEP to have a more flushed out
reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't
want to do it I can try to instil my blog post into a more succinct
paragraph or two and update the PEP myself.
> Is this going to require a PEP or if we can agree on the points here are
we just going to do it? If we think it requires a PEP I'm willing to write
it, but I obviously have no issue if we skip that step either. :)
> Oh, and we should resolve this before the next release of Python 3.4,
3.5, or 3.6 so that pathlib can be updated in those releases.
> -Brett
> On Wed, 6 Apr 2016 at 08:09 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
>> >> 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.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160406/c567a534/attachment-0001.html>

More information about the Python-Dev mailing list