On Wed, Oct 21, 2020 at 07:17:21PM -0700, Guido van Rossum wrote:
> Hmm, if the above is acceptable, maybe f-strings are still the logical next
> step, since they bring the format and the target name together again.
That's not the only way to bring the format and target name together.
Both brace-style and percent-style can do that:
'{number:d}'
'%(number)d'
I'm not sure if you've caught up on the entire thread, but Eric Smith is
opposed to this:
https://mail.python.org/archives/list/[email protected]/message/KTGQLT4TY672GRF6JFV6MZHUE4J4S3NS/
(For the benefit of those who aren't aware of the f-string history, Eric
wrote the PEP and at least part of the implementation.)
f-strings also bring so much more to the table than is needed. For this
syntax to be sensible, we would have to prohibit so many legal f-strings
that it seems perverse to continue calling the subset of what's left
over f-strings.
1. They don't behave like f-strings: text scanning, not evaluation of
code. What meaning could we give an f-string target like this?
f'{len(x)+1}' = string
2. They don't support the same formatting options as f-strings.
Chris has suggested a superset of formatting options, similar to
regexes; other f-string codes would be meaningless:
f'a {spam:^5_d} b' = 'a 1234 b'
# centre align; group digits using underscore
3. As Eric explains, they don't share the same mechanism as f-strings.
4. Actual f-strings need the prefix to distinguish them from regular
strings. But as an assignment target, there is no existing meaning to
'email: {name}@{domain}' = string
so the f prefix has no purpose.
When they have so little in common with f-strings, apart from a spurious
and unnecessary f-prefix, why are we calling them f-strings?
Another problem is that using only a literal/display form as a target
means you can't pre-assemble a pattern and apply it later:
# Match only the given domain.
domain = get_wanted_domain()
pattern = 'email: {name}@%s' % domain
# ... now what?
I guess you could fall back to eval:
eval('f{!r} = {!r}'.format(pattern, string))
but given that both the pattern and the string to be scanned are likely
to contain untrusted strings, that's probably not a good idea.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/TAI5XYYEKEYSMDJKIE3Y6LXMVZQLJDIT/
Code of Conduct: http://python.org/psf/codeofconduct/
