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.)

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 -- 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/TAI5XYYEKEYSMDJKIE3Y6LXMVZQLJDIT/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to