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

[Sven R. Kunze]

On 29.03.2016 15:08, Paul Moore wrote:
> On 29 March 2016 at 13:31, Sven R. Kunze <srkunze at mail.de> wrote:
>> That as well needs to be fixed but it's no argument for delaying other
>> improvements, right?
> Certainly. However, I don't think p-strings are an improvement - I'm
> not suggesting delaying them because other things need to be fixed,
> I'm suggesting that the whole proposal shouldn't be implemented
> because it's not a good idea.

Alright. Got it. :)

p-strings are not the most pressing issue of pathlib I assume. Wrapping 
an (f-)string into a Path might work for now although I would love see 
the convenient p-string in some future Python version.

> If you want custom string-like syntaxes, PEP 501 is where you should
> be getting involved. Adding a single-purpose custom string prefix is a
> proposal that *should* be delayed until the fate of a more general
> proposal of which it's a subset is decided. Because once syntax is
> added it's nigh-on impossible to get rid of.

Agreed. First things first.


Note on PEP 501. Not sure if I like it (sorry Nick) but to me it feels a 
bit artificial/impracticable.

Its examples seem very awkward to me. This additional pair of 
parentheses kills it for me. runquery & runcommand should do the 
wrapping themselves. If done, i-strings look like f-strings.

runquery(sql(i"SELECT {column} FROM {table};"))
runcommand(sh(i"cat {filename}"))


This means for p-string:

Path(f'/whereever/{youwant}/{togo}') == p'/whereever/{youwant}/{togo}'

So, if Path is powerful enough, I think most people can live with that 
for now  (but those parentheses .... don't we already have the quotation 
marks ... anyway) ;-)


Best,
Sven