[Python-ideas] Let’s make escaping in f-literals impossible
Philipp A.
flying-sheep at web.de
Tue Aug 23 04:30:20 EDT 2016
Sorry for replying to late, i had an email issue.
First two important things: 1. mental model and intuition and 2.
precendence.
About how to think of them: I’m strongly of the opinion that the mental
models of either an alternating sequence of strings and formatted
expressions, or a string with “holes” for expressions, are better than “a
string where parts are magically evaluated after it’s created”. That smells
like “eval” instead of the usual separation of data and code. That’s the
same reason I dislike calling them “f-strings”: they’re undoubtedly
**expressions
evaluating to strings**, not string literals.
Precedence exists in ruby’s and CoffeeScript’s string interpolation, Bash’s
$(), JavaScript’s template literals, and many more:
https://en.wikipedia.org/wiki/String_interpolation
!!! *All* of them that support arbitrary code (And that I ever encountered)
work the way I propose for python to work
@Brett Cannon: Pragmatism is only good as long as it only compromises on
elegance, not usability. I think “partly evauable f-strings” are harder to
use than “f-literals with string and expression parts”
@Chris Angelo: All those things being illegal is surprising, which is
another argument in favor of my proposal.
@Guido van Rossum I’d rather not like them to be preliminarily in the
language in this form, considering Python’s track record of not changing
preliminary things anymore…but: @Eriv V. Smith: Great idea with banning all
backslashes for now. This is so close to release, so we could ban escape
sequences and use all of the existing code, then write a new RFC to make
sure things are optimal (which in my eyes means the holes/alternating
sequence model instead of the thing we have now)
Thank you all for your contributions to the discussion and again sorry for
messing up and only now posting this correctly.
Best, Philipp
Chris Angelico <rosuav at gmail.com> schrieb am So., 21. Aug. 2016 um
09:57 Uhr:
> On Sun, Aug 21, 2016 at 5:51 PM, Franklin? Lee
> <leewangzhong+python at gmail.com> wrote:
> > Speaking of which, how is this parsed?
> > f"{'\n'}"
> > If escape-handling is done first, the expression is a string literal
> holding
> > an actual newline character (normally illegal), rather than an escape
> > sequence which resolves to a newline character.
>
> It's illegal.
>
> > If that one somehow works, how about this?
> > f"{r'\n'}"
>
> Also illegal.
>
> > I guess you'd have to write one of these:
> > f"{'\\n'}"
> > f"{'''\n''')"
> > rf"{'\n'}"
>
> Modulo the typo in the second one, these all result in the same code:
>
> >>> dis.dis(lambda: f"{'\\n'}")
> 1 0 LOAD_CONST 1 ('\n')
> 2 FORMAT_VALUE 0
> 4 RETURN_VALUE
> >>> f"{'\\n'}"
> '\n'
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160823/d6021e0e/attachment.html>
More information about the Python-ideas
mailing list