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

Brett Cannon brett at python.org
Fri Apr 8 13:32:23 EDT 2016

On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven <k7hoven at gmail.com> wrote:

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 ;).

Since I kicked up the discussion here on python-dev, I can explain what happened.

After the python-ideas threads kicked up I realized I was not using pathlib in importlib and there were a handful of places it could be supported. But since pathlib is provisional I didn't want to have to start making the stdlib support it if we removed the whole module itself. So I simply asked over here on python-dev what it would take to remove the provisional label from pathlib. People then pulled over the python-ideas discussion of what people were upset about in regards to pathlib to help decide what it would require to remove the provisional label and the conversation forked (I also assumed Guido and others had muted the discussion over on python-ideas so it would have been a new thread somewhere regardless). And then when I realized what had happened I was going to reply to one of your emails on python-ideas to point out the bifurcation but someone beat me to it.

So the whole thing just became a tangled mess of discussion. :) I viewed the threads on improving pathlib as separate from a discussion of what the requirements were to remove the provisional label and very specific to python-dev since this isn't an idea of a concrete development/maintenance question, but people tied the two together and that's how we ended up here. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20160408/5a506dfe/attachment.html>

More information about the Python-Dev mailing list