> f(**{u, v})

I think a fundamental point is that `**{identifier}` looks like
you are applying `**` unpacking to a set, but you actually aren't, it is
a special syntactic form. If that disturbs you, I'm not going to say you are wrong.

The special syntactic form doesn't bother me that much.  '**dict' is already a syntax error in many places, but allowed in a few other places.

I also do not think the purpose served is important enough to warrant a new special form.  The actual same conciseness can be achieved with a function that does just a little bit of magic, e.g.:

    func(**Q(u, v))

Someone linked to a library that apparently does the magic a bit better than my 5-minute version (which required quoting the variable names).  I think it was you who complained that sys._getframe() might be CPython specific, which is true.  But probably other implementations could do different magic to make their own Q(), so that seems of little importance.

I'd be only -0.5 on any proposal from this thread (as opposed to -1000 as I am now) if it were more general purpose than just function calls. Like David's "Q" function (which is an actual function), if we had some magic that said "create a dict from these names, where the values come from normal python scoping rules". Let's say that magic function is named M() (for magic). We might want it to be special syntax to make it clear it's magic (maybe "!<a, b>": who knows, and it's unimportant here). But that's not the point: the point here is making something general purpose.

So, if M() existed, you could say:

d = M(telephone, name)
func(**d)

or

func(**M(telephone, name))

Or, you could just use "d" from the first example for your own purposes unrelated to function calling.

My point is: We already have a way to pass the items in a dictionary as keyword args: let's not invent another one. Instead, let's focus on a general purpose way of creating a dictionary that meets the requirements of being able to be passed as keyword args. That way we'd me making the language more expressive beyond just function calls.

Eric