[Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 10:36 Michel Desmoulin <desmoulinmichel at gmail.com>
wrote:

> Wouldn't be better to generalize that to a "__location__" protocol,
> which allow to return any kind of location, including path, url or
> coordinate, ip_address, etc ?
>

No because all of those things have different semantic meaning. See the
__index__ PEP for reasons why you would tightly bound protocols instead of
overloading ones like __int__ for multiple meanings.

-Brett


>
> Le 06/04/2016 19:26, Brett Cannon a écrit :
> > 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:
> >
> >  1. Name: __path__, __fspath__, or something else?
> >  2. 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)
> >  3. Built-in? (name is dependent on #1 if we add one)
> >  4. 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 it)
> >  5. Expand the C API to have something like PyObject_Path()?
> >
> >
> > 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
> > <mailto: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
> >     <mailto:njs at pobox.com>> wrote:
> >     >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan at gmail.com
> >     <mailto: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.
> >
> >
> >
> > _______________________________________________
> > 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/desmoulinmichel%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/18a9b81f/attachment.html>