On Wed, Oct 21, 2020 at 10:49:41AM +1100, Chris Angelico wrote:
On Wed, Oct 21, 2020 at 10:39 AM Steven D'Aprano <steve@pearwood.info> wrote:
The f-string has to be a literal - it's not a magic object that you can assign to and new locals appear.
Well, no, it's not an object at all, but surely "you can assign to and new locals appear" is the whole point of the feature? You assign to the f-string and it matches values from the string on the right hand side to create new locals, or over-write existing ones.
f"{name}: {value:d}" = "eleventytwo: 112"
will have the side effect of binding:
name = "eleventytwo" value = 112
Yes. It's *not an object*.
True. It's also not a list comprehension, or an import. Why does that matter? I think either we're talking past each other, or you're trying to squirm out of admitting that the whole point of this proposal is to do what you said it doesn't do, namely bind values to names. I don't see why not being an object makes a difference.
The "spooky action at a distance" thing that I was responding to can't be an issue because the assignment is right there.
But it is an issue for the very reason I gave: even if the pattern matching fails, it can still create or overwrite variables. Normal name binding doesn't work like that: a, b, c, d = 1, 2, 3 does not bind to a, b, c. Your take on this proposal would. You see that as a feature: "partial parsing". I, and a number of other people including the OP Dennis, see that as a problem, not a feature.
Please, don't make me repeat all the same arguments again. Read the existing thread.
I have read the entire thread. Just because I disagree with you doesn't mean I haven't read your take on it. If you want to change my mind, you need to be more persuasive in your arguments, not more dismissive of objections. -- Steve