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

[Michel Desmoulin]

Le 25/03/2016 21:20, Koos Zevenhoven a écrit :
> 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.
>>
> 
> Yeah, and regarding the "`to_file()` method for strings" thread, one
> could simply do
> 
>     p"targetfile.txt".write_text(string_to_write)

It's nice. It remains me of the proposal for odereddict with o{}.

There is a limited number of prefix we can use though.

> 
> using the write_text method introduced to Path objects in 3.5. [And of
> course there's also read_text(), write_bytes(...) and read_bytes()]
> 
> One downside to p-strings like this is that they don't help you when
> you have the path in a plain str variable (i.e. not a literal), which
> has led me to think Path perhaps should be in builtins. But one thing
> that just occured to me now is that, for instance in interactive
> sessions, you could do
> 
>     p"" / path_as_str

> 
> instead of `import pathlib; pathlib.Path(path_as_str)`. Not sure if
> this is the most beautiful thing ever seen, but it would work for
> quick scripting at least.
> 
>> 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.
>>
> 
> Yeah, having Path subclass str would immediately solve a lot of
> compatibility issues. One question is how large a part of those issues
> would be solved by just making the builtin open(...) and a few places
> here and there in the stdlib accept Path objects. Maybe there are
> implementation issues too, although having them lead to bad decisions
> would be sad.

Although path.py, which I have been using for years now (and still
prefer to pathlib) subclass str and never caused any problem whatsoever.
So really, we should pinpoint where it could be an issue and see if this
is a frequent problem, because right now, it seems more a decision based
on purity than practicality.

> 
> 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.
> 
>  - Koos
> _______________________________________________
> 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/
>