On 7/18/2020 6:23 AM, emmanuel.coirier@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