(original) (raw)

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 ?

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@stoneleaf.us
\> ethan@stoneleaf.us>> wrote:
\>
\> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
\> > On 6 April 2016 at 16:53, Nathaniel Smith <njs@pobox.com
\> njs@pobox.com>> wrote:
\> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan@gmail.com
\> ncoghlan@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@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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org