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 '**').
On Sun, Apr 19, 2020 at 5:01 PM Alex Hall <alex.moj...@gmail.com> wrote:
> 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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/B7V5Y65Q7AFY6OWGEFTZJPG3OZMBPKWR/
Code of Conduct: http://python.org/psf/codeofconduct/
