On 11/23/20 1:49 PM, David Mertz wrote:
On Mon, Nov 23, 2020, 4:32 PM Eric V. Smith
I just commented on Steve's post over on Discourse. The problem with this is
that the called function (m.case, here)
needs to have access to the caller's namespace in order to resolve the
expressions, such as StringNode and PairNone.
This is one of the reasons f-strings weren't implemented as a function, and is
also the source of many headaches
with string type annotations.
Is this really true though? Yes, it would require magic of the sort zero-argument `super()` does. But can't the Matcher
constructor capture the locals one step up the stack on instance creation? That's largely why my strawman version is
slightly different from Steve's strawman.
I'd put the question this way: assuming Matcher can be written (with a bit of stack magic), and assuming that the
strings inside m.case() calls are exactly the same mini-languague PEP 634 proposes, would you want a syntax change?
That's not rhetorical, I'm of mixed feeling myself.
I would, yes. Writing Python code in strings to be processed by another
function/library is a pain:
- no syntax highlighting because the code is in a string
- no syntax checking because the code is in a string
- lots of quotes because the code is in a string
All in all, it feels very inelegant to me.
--
~Ethan~
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/VPG7WYZ35QFR7X2OA73ET3IM5C4HGHMV/
Code of Conduct: http://python.org/psf/codeofconduct/
