On 21.04.2020 04:25, Andrew Barnert via Python-ideas wrote: > On Apr 20, 2020, at 16:24, M.-A. Lemburg <m...@egenix.com> wrote: >> >> On 20.04.2020 19:43, Andrew Barnert via Python-ideas wrote: >>>> On Apr 20, 2020, at 01:06, M.-A. Lemburg <m...@egenix.com> wrote: >>>> >>>> The current version already strikes me as way too complex. >>>> It's by far the most complex piece of grammar we have in Python: >>>> >>>> funcdef: 'def' NAME parameters ['->' test] ':' [TYPE_COMMENT] >>>> func_body_suite >>> >>> But nobody’s proposing changing the function definition syntax here, only >>> the function call syntax. Which is a lot less hairy. It is still somewhat >>> hairy, but nowhere near as bad, so this argument doesn’t really apply. >> >> True, I quoted the wrong part of the grammar for the argument, >> sorry. I meant this part: >> >> https://docs.python.org/3/reference/expressions.html#calls >> >> which is simpler, but not really much, since the devil is in >> the details. > > Let’s just take one of the variant proposals under discussion here, adding > ::identifier to dict displays. This makes no change to the call grammar, or > to any of the call-related bits, or any other horribly complicated piece of > grammar. It just changes key_datum (a nonterminal referenced only in > dict_display) from this: > > expression ":" expression | “**” or_expr > > … to this: > > expression ":" expression | “::” identifier | “**” or_expr > > That’s about as simple as any syntax change ever gets. > > Which is still not nothing. But you’re absolutely right that a big and messy > change to function definition grammar would have a higher bar to clear than > most syntax proposals—and for the exact same reason, a small and local change > to dict display datum grammar has a lower bar than most syntax proposals.
I think the real issue you would like to resolve is how to get at the variable names used for calling a function, essentially pass-by-reference (in the Python sense, where variable names are references to objects, not pointers as in C) rather than pass-by-value, as is the default for Python functions. The f-string logic addresses a similar need. With a way to get at the variable names used for calling a function from inside a function, you could then write a dict constructor which gives you the subset of vars() you are looking for. If you know that the variable names used in the function are the same as in the calling context, you can already do this using introspection. For the general purpose case, I don't think this is possible without the help of the compiler, since the pass-by-value is implemented using the bytecodes and the stack, AFAIR. Rather than using new syntax, a helper in the compiler would do the trick, though, similar to what e.g. @classmethod does. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Apr 21 2020) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ _______________________________________________ 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/MBNJQ4IDT7THGQT2WMNAQKCFZWEOZPUN/ Code of Conduct: http://python.org/psf/codeofconduct/
