This is an answer to "what PEP 634 proposes":
On Fri, 4 Dec 2020 at 19:18, Jim J. Jewett email@example.com wrote:
(...) I'm getting a bit confused over when people mean "the PEP currently says" vs "the implementation probably should" vs "the PEP should additionally require" vs "the PEP should instead say".
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.
case (a, b, c) if f(): # assume f() returns false
This will guarantee binding of a, b, and c when the subject is a sequence of 3 elements. Otherwise, which are assigned is implementation defined. Nothing of this is affected in any way by the behaviour of f, and the binding is guaranteed to be done before f is called.
case (a, b) if a == c: # is a still bound from case above? Is that
This will guarantee binding of a and b when the subject is a sequence of 2 elements. Otherwise, which are assigned is implementation defined. Nothing of this is affected in any way by the behaviour of a==c, and the binding is guaranteed to be done before the equality is computed.
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?
This is a SyntaxError, (d=a) is not a pattern.
To summarize: * on a successful match of the *pattern* (ignoring the guard), all captured variables are bound, and that happens before the guard is evaluated * on a failed match, an arbitrary subset of the variables may be bound, and the guard is guaranteed to not be evaluated.
My previous belief was that this was implementation defined, because the
cases could be processed in parallel, so that the first case might not have finished by the time variable a was needed in the later cases. My reading of PEP 634 suggests that there is a linearization, but only of the guards, so ... now I am not sure.
-jJ _______________________________________________ Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/F5KRIPR4... Code of Conduct: http://python.org/psf/codeofconduct/