[Python-Dev] Defining a path protocol (original) (raw)

Brett Cannon brett at python.org
Wed Apr 6 14:32:07 EDT 2016

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 PyObjectPath()? 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>

More information about the Python-Dev mailing list