On 29.03.2016 15:08, Paul Moore wrote:
On 29 March 2016 at 13:31, Sven R. Kunze srkunze@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