On 10/22/2020 5:21 AM, Steven D'Aprano wrote:
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/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.)
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
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.
_______________________________________________
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/FCDSYIMKRYRWMPWMOUTTPG54VQ7CZWIJ/
Code of Conduct: http://python.org/psf/codeofconduct/
