5 ms·

Python: Acceptance of Pattern Matching – PEP 634

48 points by potomak 6y ago

JNRowe 6y ago
Direct links to the PEPs themselves, to perhaps save others a little time. Accepted: Specification https://www.python.org/dev/peps/pep-0634/ https://www.python.org/dev/peps/pep-0634/ Motivation and Rationale https://www.python.org/dev/peps/pep-0635/ https://www.python.org/dev/peps/pep-0635/ Tutorial https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/ Rejected: Unused variable syntax https://www.python.org/dev/peps/pep-0640/ https://www.python.org/dev/peps/pep-0640/ Explicit Pattern Syntax for Structural Pattern Matching https://www.python.org/dev/peps/pep-0642/ https://www.python.org/dev/peps/pep-0642/
pansa2 6y ago
It's interesting that pattern matching has been accepted despite a poll showing a majority (65%) of core developers opposed to this particular proposal, and a plurality (44%) opposed to pattern matching altogether. https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770 https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...
- deleted 6y ago
  [deleted]
- rcxdude 6y ago
  I'm not sure if you can read the 'accept 634 + another' options as opposed to 'accept 634' (that said you can't necessarily read it as in support of it either. This poll is a bit of a mess in that regard). But it's certainly contentious (all options including accepting 634 still only comes to 50%).
  - pansa2 6y ago
    > I'm not sure if you can read the 'accept 634 + another' options as opposed to 'accept 634' However, I’d say that “accept 634 + another” is clearly opposed to “accept 634 & reject both others”, which is the decision that has been made.
    - rcxdude 6y ago
      What matters (if the intent is to accurately determine the preferences of those voting) is whether those voting for those options would prefer rejecting all options or only accepting 634 (hence why ranked-choice voting is a thing). Either way it would probably be healthier for a larger consensus to form before committing to a decision.
- pfalcon 6y ago
  Don't forget that the poll is dated 2020-11-20 (and majority of votes were cast soon). There was a lot of discussion (and thus maybe elaboration of opinions) since that.
pansa2 6y ago
Is it still the case that these two pieces of code have different behaviour? match status: case 404: return "Not found" not_found = 404 match status: case not_found: return "Not found" IIRC in an earlier proposal, the former would check for equality (`status == 404`) and the latter would perform an assignment (`not_found = status`).
- bilboa 6y ago
  Yes, the variable names in the case patterns are treated like variables on the left hand side of an assignment statement. Whatever value they may have had before is irrelevant. A pattern which consists solely of a variable name is a wildcard pattern that matches anything, just as it would be on the left side of an assignment. Edit: It is possible to use constants or variables in a case pattern, but they have to be dotted names to not be treated like a capture pattern. So this would work for your example: class HttpStatus(Enum): NOT_FOUND = 404 match status: case HttpStatus.NOT_FOUND: return "Not found"
  - wodenokoto 6y ago
    Do you know what would happen with: def _id(x): return x not_found = 404 match status: case _id(not_found): return "Not found"
- airstrike 6y ago
  Yes, and this is incredibly disappointing. Couldn't we achieve the same functionality with a little less ambiguity using the following syntax?: not_found = 404 match status: case not_found: return "Not found" case _ as foo: do_something(foo) return "Match anything" it even works for the example in PEP 365 match json_pet: case {"type": "cat", "name": _ as name, "pattern": _ as pattern}: return Cat(name, pattern) case {"type": "dog", "name": _ as name, "breed": _ as breed}: return Dog(name, breed) case _: raise ValueError("Not a suitable pet")

48 points by potomak 6y ago

Direct links to the PEPs themselves, to perhaps save others a little time. Accepted: Specification https://www.python.org/dev/peps/pep-0634/ https://www.python.org/dev/peps/pep-0634/ Motivation and Rationale https://www.python.org/dev/peps/pep-0635/ https://www.python.org/dev/peps/pep-0635/ Tutorial https://www.python.org/dev/peps/pep-0636/ https://www.python.org/dev/peps/pep-0636/ Rejected: Unused variable syntax https://www.python.org/dev/peps/pep-0640/ https://www.python.org/dev/peps/pep-0640/ Explicit Pattern Syntax for Structural Pattern Matching https://www.python.org/dev/peps/pep-0642/ https://www.python.org/dev/peps/pep-0642/

pansa2 6y ago

It's interesting that pattern matching has been accepted despite a poll showing a majority (65%) of core developers opposed to this particular proposal, and a plurality (44%) opposed to pattern matching altogether. https://discuss.python.org/t/gauging-sentiment-on-pattern-matching/5770 https://discuss.python.org/t/gauging-sentiment-on-pattern-ma...

deleted 6y ago
[deleted]
rcxdude 6y ago
I'm not sure if you can read the 'accept 634 + another' options as opposed to 'accept 634' (that said you can't necessarily read it as in support of it either. This poll is a bit of a mess in that regard). But it's certainly contentious (all options including accepting 634 still only comes to 50%).
- pansa2 6y ago
  > I'm not sure if you can read the 'accept 634 + another' options as opposed to 'accept 634' However, I’d say that “accept 634 + another” is clearly opposed to “accept 634 & reject both others”, which is the decision that has been made.
  - rcxdude 6y ago
    What matters (if the intent is to accurately determine the preferences of those voting) is whether those voting for those options would prefer rejecting all options or only accepting 634 (hence why ranked-choice voting is a thing). Either way it would probably be healthier for a larger consensus to form before committing to a decision.
pfalcon 6y ago
Don't forget that the poll is dated 2020-11-20 (and majority of votes were cast soon). There was a lot of discussion (and thus maybe elaboration of opinions) since that.

pansa2 6y ago

Is it still the case that these two pieces of code have different behaviour? match status: case 404: return "Not found" not_found = 404 match status: case not_found: return "Not found" IIRC in an earlier proposal, the former would check for equality (`status == 404`) and the latter would perform an assignment (`not_found = status`).

bilboa 6y ago
Yes, the variable names in the case patterns are treated like variables on the left hand side of an assignment statement. Whatever value they may have had before is irrelevant. A pattern which consists solely of a variable name is a wildcard pattern that matches anything, just as it would be on the left side of an assignment. Edit: It is possible to use constants or variables in a case pattern, but they have to be dotted names to not be treated like a capture pattern. So this would work for your example: class HttpStatus(Enum): NOT_FOUND = 404 match status: case HttpStatus.NOT_FOUND: return "Not found"
- wodenokoto 6y ago
  Do you know what would happen with: def _id(x): return x not_found = 404 match status: case _id(not_found): return "Not found"
airstrike 6y ago
Yes, and this is incredibly disappointing. Couldn't we achieve the same functionality with a little less ambiguity using the following syntax?: not_found = 404 match status: case not_found: return "Not found" case _ as foo: do_something(foo) return "Match anything" it even works for the example in PEP 365 match json_pet: case {"type": "cat", "name": _ as name, "pattern": _ as pattern}: return Cat(name, pattern) case {"type": "dog", "name": _ as name, "breed": _ as breed}: return Dog(name, breed) case _: raise ValueError("Not a suitable pet")