Nope, that's fine.
I reckon it's reasonable to call this inspecting the source code. I thought from your GH issue that you meant you read in a whole module of code.
I don't want my Q(), or M(), or whatever letter comes after that, in the standard library. I don't even care about making a repo for it or publishing it on PyPI. Even if you can find a way to break it... which I'm happy to stipulate you can, that doesn't matter a whit to the possible utility... if the need was genuine.
If this were in the library I or my project used, whatever limitations and edge cases exist wouldn't really matter. If I REALLY cared about saving a few duplicate names in function calls, I could easily include it with the knowledge that it won't handle such-and-such edge cases. If the improvement really mattered for normal, boring code that makes up 99% of the code I write, I could use it in that 99%. But I don't. And you don't. And no one in this thread does.... so special syntax for something no one actually does is foolish.
... that said, I like your latest suggestion best of what I've seen. I.e.
built_dict = {**, foo, bar, baz}
my_func(**, foo, bar, baz)
my_other_func(**kws, foo, bar)
Those all read nicely, and in a consistent way. You could even drop the bare ** by using:
my_func(**{}, foo, bar, baz)
(if there was a reason someone was OK with self-naming values but not with bare '**').
Per your wish, Eric, the glorious successor of Q() ... named M():
>>> def M(*vals):
... import sys
... import inspect
... caller = sys._getframe(1)
... call = inspect.stack()[1].code_context[0]
... _, call = call.split('M(')
... call = call.strip()[:-1]
... names = [name.strip() for name in call.split(',')]
... dct = {}
... for name in names:
... dct[name] = eval(name, globals(), caller.f_locals)
... return dct
...
>>> x, y, z = range(3)
>>> M(x, y, z)
{'x': 0, 'y': 1, 'z': 2}
OK, it's a little bit fragile in assuming the function must be called M rather than trying to derive its name. And maybe my string version of finding the several args could be made more robust. But anyone is welcome to improve it, and the proof of concept shows that's all we need. Basically, a "dict-builder from local names" is perfectly amenable to writing as a Python function... and we don't need to inspect the underlying source code the way I believe Alex' sorcery module does (other parts of it might need that, but not this).
I can lay out all the issues with this if you want me to, but after my previous email I don't think I have to. I'm just wondering why you say it doesn't need to inspect the underlying source code. That's what `code_context` is and that's obviously the only place where a string like `'M('` could be found, unless you want to uncompile bytecode (which is not impossible either, but it's an additional mess).
--
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons. Intellectual property is
to the 21st century what the slave trade was to the 16th.