5 ms·

Ouch, that's indeed pretty bad. I do expect `not_found = status` (that's how pattern matching works in several other languages), but it should be in its own sco

Ouch, that's indeed pretty bad. I do expect `not_found = status` (that's how pattern matching works in several other languages), but it should be in its own scope, so that `not_found` is still `404` outside of the `match` block!

pansa2 6y ago
In those other languages, if `not_found` is equal to 404 before the match block, how do you write a clause that only matches if `status` is 404? Do you have to use the integer literal 404 instead of the named integer `not_found`?
- yw3410 6y ago
  Depends on the language, but a lot of them use guard clauses (so case ... if cond =>).
- DougBTX 6y ago
  Pretty much the same as in the PEP: https://www.python.org/dev/peps/pep-0636/#adding-conditions-to-patterns https://www.python.org/dev/peps/pep-0636/#adding-conditions-...
- deleted 6y ago
  [deleted]
- heisenzombie 6y ago
  Elixir uses the “pin operator” “Use the pin operator ^ when you want to pattern match against a variable’s existing value rather than rebinding the variable.” iex> not_found = 404 404 iex> ^not_found = 200 ** (MatchError) no match of right hand side value: 200 https://elixir-lang.org/getting-started/pattern-matching.html#the-pin-operator https://elixir-lang.org/getting-started/pattern-matching.htm...
  - pfalcon 6y ago
    Exactly, Elixir is usually the only example given. So, how it makes sense to blame Python here is unclear. There's a proposal to add similar "sigils" to Python pattern matching, it just didn't make it yet.
- lou1306 6y ago
  In OCaml and F# you can use `when`: match status with | n when n = not_found -> ...
nemetroid 6y ago
Python doesn't have block scope. This can lead to some surprising behaviour: x = -1 for x in range(7): if x == 6: print(x, ': for x inside loop') print(x, ': x in outer') This outputs: 6 : for x inside loop 6 : x in outer For consistency, I think it makes sense for match to behave in a similar way.
- deleted 6y ago
  [deleted]
- CogitoCogito 6y ago
  I don't know if I even know what "being consistent" would mean given the example here: https://news.ycombinator.com/item?id=26082225 https://news.ycombinator.com/item?id=26082225 We don't shadow variables when they are re-used in comprehensions for example: >>> i = 4 >>> [i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> i 4 Given they're already accepting the oddity of having "case 404:" and "case variable:" mean very different things, I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language.
  - nemetroid 6y ago
    > We don't shadow variables when they are re-used in comprehensions for example: I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. This is not to say that I agree with the design as a whole. I think they should have went with: case obj.some_value: ... case some_value: # behaves the same way as the previous ... case _ as variable: ... case (variable := _): # an alternative to the previous syntax ... I.e. I think the complete situation is messy, but it's not the variable scoping rules' fault.
    - CogitoCogito 6y ago
      > I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The rarity of the construct doesn't matter honestly. Are you saying that list comprehensions should _not_ have introduced a new scope because it was unusual? > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. Syntactically yes, but semantically it is very different and the semantics must be taken into account as well. The example given at the top of this thread (case 404: and case variable:) is enough to convince me that having variable scoping is a brain-dead obvious requirement. > I think the complete situation is messy, but it's not the variable scoping rules' fault. I agree with that statement. I think that improving the design/semantics would be more effective than just adding some more scoping rules in. In fact, I don't think this PEP should have been accepted in this current form at all. But given the current design, block-level scoping is appropriate. Given another design like maybe those you mention might not require that, but I think focusing on the fact that python doesn't have block-level scoping makes no sense. The python language before this PEP is not the same as the one after this PEP. The new one should have block-level scoping in this instance.

pansa2 6y ago

In those other languages, if `not_found` is equal to 404 before the match block, how do you write a clause that only matches if `status` is 404? Do you have to use the integer literal 404 instead of the named integer `not_found`?

yw3410 6y ago
Depends on the language, but a lot of them use guard clauses (so case ... if cond =>).
DougBTX 6y ago
Pretty much the same as in the PEP: https://www.python.org/dev/peps/pep-0636/#adding-conditions-to-patterns https://www.python.org/dev/peps/pep-0636/#adding-conditions-...
deleted 6y ago
[deleted]
heisenzombie 6y ago
Elixir uses the “pin operator” “Use the pin operator ^ when you want to pattern match against a variable’s existing value rather than rebinding the variable.” iex> not_found = 404 404 iex> ^not_found = 200 ** (MatchError) no match of right hand side value: 200 https://elixir-lang.org/getting-started/pattern-matching.html#the-pin-operator https://elixir-lang.org/getting-started/pattern-matching.htm...
- pfalcon 6y ago
  Exactly, Elixir is usually the only example given. So, how it makes sense to blame Python here is unclear. There's a proposal to add similar "sigils" to Python pattern matching, it just didn't make it yet.
lou1306 6y ago
In OCaml and F# you can use `when`: match status with | n when n = not_found -> ...

nemetroid 6y ago

Python doesn't have block scope. This can lead to some surprising behaviour: x = -1 for x in range(7): if x == 6: print(x, ': for x inside loop') print(x, ': x in outer') This outputs: 6 : for x inside loop 6 : x in outer For consistency, I think it makes sense for match to behave in a similar way.

deleted 6y ago
[deleted]
CogitoCogito 6y ago
I don't know if I even know what "being consistent" would mean given the example here: https://news.ycombinator.com/item?id=26082225 https://news.ycombinator.com/item?id=26082225 We don't shadow variables when they are re-used in comprehensions for example: >>> i = 4 >>> [i for i in range(10)] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> i 4 Given they're already accepting the oddity of having "case 404:" and "case variable:" mean very different things, I think they should have just gone the whole way and _not_ mutated outside variables. There seems to be little consistent with this addition to the language.
- nemetroid 6y ago
  > We don't shadow variables when they are re-used in comprehensions for example: I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. This is not to say that I agree with the design as a whole. I think they should have went with: case obj.some_value: ... case some_value: # behaves the same way as the previous ... case _ as variable: ... case (variable := _): # an alternative to the previous syntax ... I.e. I think the complete situation is messy, but it's not the variable scoping rules' fault.
  - CogitoCogito 6y ago
    > I think "for example" makes this sound more general than it is. List comprehensions are one of the rare few constructs that introduce a new scope. The rarity of the construct doesn't matter honestly. Are you saying that list comprehensions should _not_ have introduced a new scope because it was unusual? > The match block is more syntactically similar to if/while/etc. blocks, and so it makes sense that it would follow similar scoping rules. Syntactically yes, but semantically it is very different and the semantics must be taken into account as well. The example given at the top of this thread (case 404: and case variable:) is enough to convince me that having variable scoping is a brain-dead obvious requirement. > I think the complete situation is messy, but it's not the variable scoping rules' fault. I agree with that statement. I think that improving the design/semantics would be more effective than just adding some more scoping rules in. In fact, I don't think this PEP should have been accepted in this current form at all. But given the current design, block-level scoping is appropriate. Given another design like maybe those you mention might not require that, but I think focusing on the fact that python doesn't have block-level scoping makes no sense. The python language before this PEP is not the same as the one after this PEP. The new one should have block-level scoping in this instance.