On 12/4/20 11:15 AM, Jim J. Jewett wrote:
To be more specific, I'm not sure what is intended for the 2nd or 3rd case below, which
reuse a variable "bound" by the first (failed) match. Nor am I sure whether it
matters that the first match fails on the guard predicate, instead of immediately on the
match.
Here's my understanding of it:
case (a, b, c) if f(): # assume f() returns false
a, b, and c and are initially bound from matches to the object in question, whether they remain bound after f() fails is
implementation dependent and should not be relied upon
case (a, b) if a == c: # is a still bound from case above? Is that
implementation-dependent?
a and b are initially bound from matches to the object in question, and the `a` in `a == c` has that new value; `c`,
however, could be the `c` from the first, failed, match -- presumably this is simply a bug in the above match block
because it seems like a bad idea to overwrite an already present variable (`c` in this case) in a first match when later
matches depend on it.
case (d = a): # is a still bound from case above? Is that
implementation-dependent? Is it even still possible to put restrictions in
before the guard clause, like d=4?
`a` is bound to the `d` attribute of the match object.
The implementation defined aspect is whether names remain bound after match and/or guard failures. In the above code
that uncertainty only affects the name `c` as it's the only one used both inside one match and in a guard in a different
match.
--
~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/AUOET7RISAQM2CK565FALM2ZBFFOIUPI/
Code of Conduct: http://python.org/psf/codeofconduct/
