This is an answer to "what PEP 634 proposes": On Fri, 4 Dec 2020 at 19:18, Jim J. Jewett <jimjjew...@gmail.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 > implementation-dependent? > 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 -- 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/F5KRIPR4HUDG6TIUWLYBD6CBUFKPLYVF/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/V5DDEGA6CQLBQCMMRCS5QUKGTN37R6BC/ Code of Conduct: http://python.org/psf/codeofconduct/
