> A really good example here is the p"C:\" question. Is the
> proposal that the "string part" of the literal is just a normal
> string? If so, then how do you address this genuine issue
> that not all paths are valid? What about backslash-escapes
> (p"C:\temp")? Is the string a raw string or not? If the
> proposal is that the path-literal code can define how the
> string is parsed, then how does that work?
I don't usually work with windows, but I can see how this could
be a pain point for windows users. They need both backslashes
and the quotation marks in their paths.
As nobody has suggested yet how to deal with the problem,
I'd like to give it a try. Behold:
p{C:\}
The part within the curly braces is considered a "really-raw"
string. The "really-raw" means that every character is interpreted
exactly as it looks, there are no escape characters. Internal braces
will be allowed too, provided that they are properly nested:
p{C:\"Program Files"\{hello}\}
If you **need** to have unmatched braces in the string, your last
hope is the triple-braced literal:
p{{{Letter Ж looks like }|{... }}}
The curly braces can only be used with a string prefix (or suffix?).
And while we're at it, why not allow chained literals:
re{(\w+)}{"\1"}
frac{1}{17}
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/RDDQSNZF3WT47FXIVXJTVPIO3DQN5Z52/
Code of Conduct: http://python.org/psf/codeofconduct/
