On 7/18/2020 6:23 AM, emmanuel.coir...@caissedesdepots.fr wrote:
Ethan Furman wrote:
The problem with any kind of sigil/keyword is that it becomes line noise
-- we would have to train ourselves to ignore them in order to see the
structure and variables we are actually interested in. Once we become
[snip much]
On the other hand, "capturing" variables mixed with "match" variables is
counter-intuitive unless you explicitly learn the rules. You can't deduce it (there rules don't
exist anywhere else). This feature is central of the PEP and will be used, and will introduce
subtle bugs when misused.
That's why I consider the rules you stated is not the right way for this
feature, and that we should be explicit.
It seems to me that whether one expects simple names in case headers to
be sources or targets depends on how one analogizes the match code in
case headers. If one sees it as analogous to imperative elif
conditions, where names are value sources, then one likely expects that.
If one sees match code as analogous to target or parameter lists,
where names declare binding targets, then one like expect that behavior
instead.
Both analogies are inexact because match code needs to have both sources
and targets. Different people will have different preferences and
expectations.
I happen to prefer the parameter list analogy because conditions are
executable expressions while match code is not and by intention is
partly to mostly declarative, with the implementation in logic and
expressions left to the compiler.
--
Terry Jan Reedy
_______________________________________________
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/LJHGWWKYBCAK64AYHISY3JC63VKEOI2G/
Code of Conduct: http://python.org/psf/codeofconduct/
