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 "
", 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