[Python-ideas] Working with Path objects: p-strings?

[Michel Desmoulin]

Le 26/03/2016 11:44, Andrew Barnert via Python-ideas a écrit :
> On Mar 25, 2016, at 13:20, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>>
>> So, let's start a new thread about how to deal with pathlib.Path
>> objects, involving how/whether to convert between str and Path.
>>
>> On Fri, Mar 25, 2016 at 7:14 PM, Sven R. Kunze <srkunze at mail.de> wrote:
>>>> On 24.03.2016 22:06, Koos Zevenhoven wrote:
>>>>
>>>> Or even better, that you could do p"filename.txt", which would give you a
>>>> Path string object. Has this been discussed?
>>>
>>> Interesting. I had this thought half a year ago. Quite recently I mentioned
>>> this to Andrew in a private conversation.
>>
>> Yeah, I first thought about this at some point last summer when I had
>> written the little np package for creating numpy arrays as np[3,4,5]
>> (which I am planning to polish and maybe advertise), probably also
>> inspired by the f-string discussions on this list. And now that you
>> asked me about dealing with Paths...
>>
>> Anyway, as you say, if different people have thought about this
>> independently, maybe its worth discussing.
>>
>>> p'/etc/hosts' would make a perfect path which subclassed from str.
> 
> Having Path types subclass str would solve 90% of the problems with pathlib. Adding p-strings raises that to 91%; I don't think it's enough extra win to be worth it.
> 
> The main reason not to use pathlib today is that almost nothing takes Path objects. A handful of functions (open, stat, access) have methods on the Path objects. But if you want to zlib.open a Path, or add one to a ZipFile, or pass one to json.load or etree.parse, or use it with any third-party library, you have to convert to str manually. And in the opposite direction, paths you get from sys.argv or WSGI or anywhere else are str, not Path, so you have to construct Path objects manually too. So, attempting to use Path all over the place means converting back and forth to str all over the place. And the benefit of having Path objects is so tiny that it's not worth the cost.
> 
> Path seems to have been designed for a statically-typed language with implicit conversions. In fact, it's very similar to the Boost/C++ design. But that design works for C++ because every time you pass a path to a function that wants a string, or try to store a string in a path-typed variable, the compiler sees what you're doing, sees that the types are unrelated, and looks for a conversion operator or constructor so it can insert an implicit call. That doesn't, and can't, happen in Python.
> 
> As mentioned in one of the other replies, pathlib's main PyPI predecessor does subclass str, and that makes it a lot more usable.
> 
>>> The p-string idea has not been discussed in the PEP I think. The subclassing
>>> thing however was and I think its resolution was a mistake. The explanation,
>>> at least from my point of view, is a bit weird.
> 
> I assume there are good arguments against making Path inherit from str. Unfortunately, those arguments don't seem to appear in the PEP. They really should. But, given that they don't, anyone proposing a change like this really should go back and look at the archived previous discussions, summarize and link the old arguments, and offer counter-arguments.
> 
>> Anyway, I think the question of whether Path should subclass str is
>> partly separate from the p-string concept. After all, b'byte strings'
>> are not subclassed from str either.
> 
> Well, adding p-strings but _not_ subclassing str seems to add almost nothing. It makes it easier to construct literal Path objects that you still can't use anywhere, so you end up writing "spam(str(p'eggs.txt'))" instead of just "spam('eggs.txt')"?
> 

+1 to everything.

Remember that because of this, all projects I work on still use path.py.
We prefer to add an additional dependency than to deal with the casting,
because it spreads everywhere. And we are not a conservative crew, some
projects use Python 3.5 and asyncio.

Although honestly, p'/foo/bar'.write_text(stuff) would be awesome at
some many levels. Can you imagine how scripting becomes easier because
of this ? Sys admin ? Shell sessions ?

> But I agree that they can be separated, for the opposite reason: a str-subclassing Path is useful with or without p-strings.
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>