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__
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.
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.
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.
5. Expand the C API to have something like PyObject_Path()?
No opinion.
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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com