[Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 11:06 Ethan Furman <ethan at stoneleaf.us> wrote:

> On 04/06/2016 10:26 AM, Brett Cannon 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.
>
> Excellent!  Let's proceed along this path ;) until somebody objects.
>
>
> > Now we need clear details. :) Some open questions are:
> >
> >  1. Name: __path__, __fspath__, or something else?
>
> __fspath__
>

+1 for __path__, +0 for __fspath__ (I don't know how widespread the notion
that "fs" means "file system" is).


>
>
> >  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)
>
> I would prefer an attribute, but yeah I think dunders are typically
> methods, and I don't see this being special enough to not follow that
> trend.
>

Depends on what we want to tell 3rd-party libraries to do to support
pathlib if they are on 3.3 or if they are worried about people using Python
3.4.2 or 3.5.1. An attribute still works with `getattr(path, '__path__',
path)`. But with a method you probably want either `path.__path__() if
hasattr(path, '__path__') else path` or `getattr(path, '__path__', lambda:
path)()`.


>
>
> >  3. Built-in? (name is dependent on #1 if we add one)
>
> fspath() -- and it would be handy to have a function that return either
> the __fspath__ results, or the string (if it was one), or raise an
> exception if neither of the above work out.
>

So:

  # Attribute
  def fspath(path):
      hasattr(path, '__path__'):
          return path.__path__
      if isinstance(path, str):
          return path
      raise NotImplementedError  # Or TypeError?

  # Method
  def fspath(path):
      try:
          return path.__path__()
      except AttributeError:
          if isinstance(path, str):
              return path
      raise TypeError  # Or NotImplementedError?

Or you can drop the isinstance() check and simply check for the
attribute/method and use it and otherwise return `path` and let the code's
duck-typing of str handle catching an unexpected type for a path. At which
point the built-in becomes whatever idiom we promote for pathlib usage that
pre-dates this protocol.



>
> >  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)
>
> I don't think that's needed.  With Path() and fspath() it's trivial to
> make sure one has what one wants.
>

If we add str.__fspath__ then the function becomes:

  def fspath(path):
      return path.__fspath__()

Which might be too simplistic for a built-in, but that also means adding it
on str would potentially negate the need for a built-in.


>
>
> >  5. Expand the C API to have something like PyObject_Path()?
>
> No opinion.
>

If we add a built-in then I say we add an equivalent function in the C API.

-Brett


>
>
> > 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.
>
> Nice.
>
>
> > 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. :)
>
> If there are no (serious?) objects I don't think a PEP is needed.
>
>
> > 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.
>
> Agreed.
>
> --
> ~Ethan~
>
> _______________________________________________
> 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/8f72722a/attachment.html>