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(a)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
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.
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.