On Wed, 6 Apr 2016 at 11:06 Ethan Furman <et...@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@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
_______________________________________________
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/archive%40mail-archive.com
