[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?) (original) (raw)

Koos Zevenhoven k7hoven at gmail.com
Fri Apr 8 12:02:04 EDT 2016

Nick Coghlan wrote:

On 7 April 2016 at 03:26, Brett Cannon <br... at python.org> wrote:

Name: path, fspath, or something else? fspath

I think I might like this dunder name because it does not clutter the list of regular methods and attributes, and is perhaps more pythonic.

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) Method, as long as there's a helper function somewhere

As a further minor benefit of it being a method, it may be easier to distinguish it from from __path__, which is an iterable attribute.

Built-in? (name is dependent on #1 if we add one) os.fspath (alongside os.fsencode and os.fsdecode) (Putting this in a module low in the dependency stack makes it easy for other modules to access without pulling in all of pathlib's dependencies)

Strong +1 on putting it in os. This should also be implemented in DirEntry, instances of which are "yielded" by os.scandir.

Also, you have a strong case regarding naming with the 'fs' prefix. It is also easier to read fspath as f-s-path than it is to read ospath as o-s-path, because ospath could also be pronounced as a single (meaningless?) word.

I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does [1]. It would be nice to have the string/path distinction especially when pathlib adoption grows larger. But who knows, maybe somewhere in the far future, no-one will care much about fspath, fsencode, fsdecode or os.path.

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) Makes sense

If added to str, it should also be added to bytes. But will that then return str or bytes? See also the next point.

Expand the C API to have something like PyObjectPath()?

PyUnicodeFromFSPath, perhaps? The return type is well-defined here, so it can be done as an alternate constructor, and the C API counterparts of os.fsdecode and os.fsencode are PyUnicode functions (specifically PyUnicodeDecodeFSDefault and PyUnicodeEncodeFSDefault)

What about DirEntry, which may have a bytes representation? I would expect the function return type of os.fspath to be Union[str, bytes], unless bytes pathnames are decoded with surrogate escapes.

[1] https://mail.python.org/pipermail/python-ideas/2016-April/039595.html

PS. I have been reading this list occasionally on the google groups mirror, and I now subscribed to it just to send this. (BTW, I probably broke the thread, as I did not have Nick's email in my inbox to reply to. Sorry about that.) I'll have to mention that I was surprised, to say the least, to find that the pathlib discussion had moved here from python-ideas, where I had mentioned I was working on a proposal. Then, I also found that the solution discussed here was seemingly an improved version of what I had proposed on python-ideas somewhat earlier [1], but did not get any reactions to. While I can only make guesses about what happened, these kinds of things easily make you go from "Hey, maybe I'll be able to do something to improve Python!" to "These people don't seem to want me here or appreciate my efforts.". Not to accuse anyone in particular; just to let people know. Anyway, I somehow got sucked into thinking deeply about pathlib etc. (which I do use). Not that I really have much at stake here, except spending ridiculous amounts of time thinking about paths, mainly during my Easter holidays and after that. I really had a hard time explaining to friends and family what the heck I was doing ;).

More information about the Python-Dev mailing list