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/python-ideas@python.org/message/KTGQLT...
(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.) Steven sums up my objects very well here. Thanks, Steven. I think we definitely should not use the "f" prefix, and using no prefix at all is
On 10/22/2020 5:21 AM, Steven D'Aprano wrote: probably better than using a new prefix. The only thing this proposal brings that couldn't be done with either a str method or with a 3rd party library is automatic variable creation/binding when the LHS is a literal. If we're seriously thinking of doing that, I'd rather it be regex based that some newly invented scanf-like (or even __format__format spec-like) "language", for lack of a better term. But again, I don't think this rises to the level of usefulness that would elevate it to needing syntax. Is: "{a:%d} {b:%d} {c:%d}" ="123 432 567" such a big improvement over: a, b, c = sscanf("%d %d %d", "123 432 567") ? Reasonable people will disagree, but I think the answer is "no", especially when you factor in the inability to use a computed value for the LHS in the first example. And if all f-strings brought to the table was the ability to use simple variables as the value to be formatted, I'd have been opposed to that as well. What's the point of: f"{a} {b} {c}" when: "{} {} {}".format(a, b, c) does the same thing? This was literally one of the proposals considered when f-strings were being designed, and I was opposed. It's the ability of f-strings to handle arbitrary expressions that gives them the usefulness (and love!) that they have. Since that's by necessity missing from the "f-strings as assignment targets" proposal (as I understand it), then I again think we could just live with a str method or library that implements this. Eric
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.