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