> 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