On Wed, Oct 21, 2020 at 12:08 PM Steven D'Aprano <steve@pearwood.info> wrote:
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:
Please explain how it's "spooky action at a distance" if it's a self-contained assignment statement? I know how much you love to argue, but really, this isn't productive. ChrisA