TL;DR: I propose the following behavior:
>>> s = "She turned me into a newt." >>> f"She turned me into a {animal}." = s >>> animal 'newt' >>> f"A {animal}?" = s Traceback (most recent call last): File "<pyshell#2>", line 1, in <module> f"A {animal}?" = s ValueError: f-string assignment target does not match 'She turned me into a newt.' >>> f"{hh:d}:{mm:d}:{ss:d}" = "11:59:59" >>> hh, mm, ss (11, 59, 59)
I do really like the idea, but assigning to a literal really makes it feel wrong...
I think the best way to implement this would be through a str method that would return a dict (so that variables don't "magically" appear out of nowhere).
Something like :
"She turned me into a newt.".parse("She turned me into a {animal}.")
{"animal":"newt"}
This, in addition with locals().update(_), feels much better to me. Furthermore, it would allow other string-like classes, such as bytes or bytearray, to use that feature.
Note that this modified version uses regular strings, not f-strings, but is that a loss ? It may even be a good thing, as f-strings are about formatting; here, it's parsing we're concerned about. We lose the invariant with = and ==, but only just.
Second point, the type conversion : I think that should be left to the user on a second, separate step. There's just too many types that would need support, and we haven't even discussed user-defined types yet ! I think we should keep it simple, and stick to strings.
Additionnally ,supporting !r as eval(...) looks rad to my hyped self, but it overlooks a major security risk (see all the stuff that's been discussed about pickle being unsafe).
I don't think such an unsafe feature should be allowed at the core of Python.
Anyway, the feature overall looks promising !
Alexis