(original) (raw)

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> wrote:
On 04/05/2016 11:57 PM, Nick Coghlan wrote:
\> On 6 April 2016 at 16:53, Nathaniel Smith <njs@pobox.com> wrote:
\>> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <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.