<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nick Coghlan wrote:<br>
> On 7 April 2016 at 03:26, Brett Cannon <<a href="mailto:br...@python.org" target="_blank">br...@python.org</a>> wrote:<br>
>><br>
>> Name: __path__, __fspath__, or something else?<br>
><br>
> __fspath__<br>
><br>
<br>
I think I might like this dunder name because it does not clutter the<br>
list of regular methods and attributes, and is perhaps more pythonic.<br>
<br>
>> Method or attribute? (changes what kind of one-liner you might use in<br>
>> libraries, but I think historically all protocols have been methods and the<br>
>> serialized string representation might be costly to build)<br>
><br>
> Method, as long as there's a helper function somewhere<br>
<br>
As a further minor benefit of it being a method, it may be easier to<br>
distinguish it from from `__path__`, which is an iterable attribute.<br>
<br>
>> Built-in? (name is dependent on #1 if we add one)<br>
><br>
> os.fspath (alongside os.fsencode and os.fsdecode)<br>
><br>
> (Putting this in a module low in the dependency stack makes it easy<br>
> for other modules to access without pulling in all of pathlib's<br>
> dependencies)<br>
<br>
Strong +1 on putting it in os. This should also be implemented in<br>
DirEntry, instances of which are "yielded" by os.scandir.<br>
<br>
Also, you have a strong case regarding naming with the 'fs' prefix. It<br>
is also easier to read fspath as f-s-path than it is to read ospath as<br>
o-s-path, because ospath could also be pronounced as a single<br>
(meaningless?) word.<br>
<br>
I'm still thinking a little bit about 'pathname', which to me sounds<br>
more like a string than fspath does [1]. It would be nice to have the<br>
string/path distinction especially when pathlib adoption grows larger.<br>
But who knows, maybe somewhere in the far future, no-one will care<br>
much about fspath, fsencode, fsdecode or os.path.<br>
<br>
>> Add the method/attribute to str? (I assume so, much like __index__() is on<br>
>> int, but I have not seen it explicitly stated so I would rather clarify it)<br>
><br>
> Makes sense<br>
<br>
If added to str, it should also be added to bytes. But will that then<br>
return str or bytes? See also the next point.<br>
<br>
> Expand the C API to have something like PyObject_Path()?<br>
><br>
> PyUnicode_FromFSPath, perhaps? The return type is well-defined here,<br>
> so it can be done as an alternate constructor, and the C API<br>
> counterparts of os.fsdecode and os.fsencode are PyUnicode functions<br>
> (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)<br>
<br>
What about DirEntry, which may have a bytes representation? I would<br>
expect the function return type of os.fspath to be Union[str, bytes],<br>
unless bytes pathnames are decoded with surrogate escapes.<br>
<br>
[1] <a href="https://mail.python.org/pipermail/python-ideas/2016-April/039595.html" rel="noreferrer" target="_blank">https://mail.python.org/pipermail/python-ideas/2016-April/039595.html</a><br>
<br>
<br>
PS. I have been reading this list occasionally on the google groups<br>
mirror, and I now subscribed to it just to send this. (BTW, I probably<br>
broke the thread, as I did not have Nick's email in my inbox to reply<br>
to. Sorry about that.) I'll have to mention that I was surprised, to<br>
say the least, to find that the pathlib discussion had moved here from<br>
python-ideas, where I had mentioned I was working on a proposal. Then,<br>
I also found that the solution discussed here was seemingly an<br>
improved version of what I had proposed on python-ideas somewhat<br>
earlier [1], but did not get any reactions to. While I can only make<br>
guesses about what happened, these kinds of things easily make you go<br>
from "Hey, maybe I'll be able to do something to improve Python!" to<br>
"These people don't seem to want me here or appreciate my efforts.".<br>
Not to accuse anyone in particular; just to let people know. Anyway, I<br>
somehow got sucked into thinking deeply about pathlib etc. (which I do<br>
use). Not that I really have much at stake here, except spending<br>
ridiculous amounts of time thinking about paths, mainly during my<br>
Easter holidays and after that. I really had a hard time explaining to<br>
friends and family what the heck I was doing ;).<br></blockquote><div><br></div><div>Since I kicked up the discussion here on python-dev, I can explain what happened.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div>