On Wed, 28 Aug 2019 at 13:15, Anders Hovmöller <bo...@killingar.net> wrote:
>
> > On 28 Aug 2019, at 14:09, Piotr Duda <duda.pi...@gmail.com> wrote:
> > There is much simpler solution, just make `abc"whatever"` synatctic
> > sugar for `string_literal_abc(r"whatever", closure)` where closure is
> > object that allow read only access to variables in call site.
>
> So to use abc"foo" we must import string_literal_abc? Seems pretty confusing
> to me!
The only sane proposal that I can see (assuming that no-one is
proposing to drop the principle that Python shouldn't have mutable
syntax) is to modify the definition
stringliteral ::= [stringprefix](shortstring | longstring)
stringprefix ::= "r" | "u" | "R" | "U" | "f" | "F"
| "fr" | "Fr" | "fR" | "FR" | "rf" | "rF" | "Rf" | "RF"
to expand the definition of <stringprefix> to allow any
identifier-like token (precise details to be confirmed). Then, if it's
one of the values enumerated above (you'd also need some provison for
special-casing bytes literals, which are in a different syntax rule),
work as at present. For any other identifier-like token, you'd define
TOKEN(shortstring|longstring)
as being equivalent to
TOKEN(r(shortstring|longstring))
I.e., treat the string as a raw string, and TOKEN as a function name,
and compile to a function call of the named function with the raw
string as argument.
That's a well-defined proposal, although whether it's what people want
is a different question. Potential issues:
1. It makes a whole class of typos that are currently syntax errors
into runtime errors - fru"foo\and {bar}" is now a function call rather
than a syntax error (it was never a raw Unicode f-string, even though
someone might think it was and be glad to be corrected by the current
syntax error...)
2. It begs the question of whether people want raw-string semantics -
whilst it's the most flexible option, it does mean that literals
wanting to allow escape sequences would need to implement it
themselves.
3. It does nothing for the edge case that a trailing \ isn't allowed -
p"C:\" wouldn't be a valid Path literal.
There are of course other possible proposals, but we'd need more than
broad statements to make sense of them (specifically, either "exactly
*what* new syntax are you suggesting we allow?", or "how are you
proposing to allow users to alter Python syntax on demand?")
Paul
_______________________________________________
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/CGGDESNYMT3TA2MCY5CEYTQT5CUHTJLF/
Code of Conduct: http://python.org/psf/codeofconduct/
