6 ms·

This is how pattern matching works in any language (except for some niche languages that allow nonlinear patterns, like Curry). Many of the comments here revea

This is how pattern matching works in any language (except for some niche languages that allow nonlinear patterns, like Curry). Many of the comments here reveal a bizarre parochialism.

pansa2 6y ago
In that case, what’s the correct way to write a clause that only matches if `status` is equal to 404? Do we have to use the integer literal 404 instead of a named integer?
- _nosewings_ 6y ago
  Yes, of course. Again, this is how it works in basically every mainstream language with this feature.
  - pansa2 6y ago
    Really? It’s best practice to use a magic number rather than a name? That breaks one of the most fundamental rules for writing good code.
    - _nosewings_ 6y ago
      If you really need to compare against a variable, use an "if". The primary benefit of pattern-matching is destructuring. EDIT: It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me.
      - hnlmorg 6y ago
        No it’s not because it’s none obvious and requires a fair amount of boilerplate code. Both of which are usually idioms Python normally tries to avoid. I guarantee you this will trip up a lot of developers who are either learning the language for the first time or who Python isn’t their primary language. Worse still, the kind of bugs this will lead to is valid code with unexpected pattern matching, which is a lot harder to debug than invalid code which gets kicked out with a compiler error.
  - mannerheim 6y ago
    There are PatternSynonyms in Haskell.
- ben509 6y ago
  It will be to stick your constants in a module and use module.constant to match them. Or use an enum. Or hang them off a class.
chriswarbo 6y ago
Not the scoping rule. For example, in Haskell: let x = foo in ( case bar of x -> x, x ) This will give `(bar, foo)`: for the first element the `x` in the case will match against `bar` and return it, then that `x` will be discarded as we leave its scope; the second element uses the binding of `x` in the `let`. According to the Python semantics we would get `(bar, bar)`, since we only have one `x` variable. When the case pattern succeeds, the existing `x` is updated to refer to `bar`. Hence we get the `bar` we expect in the first element, but we also get `bar` as the second element, since that `x` variable was updated. (Note that Python guarantees that tuple elements are evaluated from left to right).
- _nosewings_ 6y ago
  That's just an inevitable consequence of the fact that, in Python, "scope" is synonymous with "dictionary attached to some object." This is already how for-loops work.
  - CogitoCogito 6y ago
    It's not "inevitable". They could have required local variables in case statements to be local to that case statement. It would have required changes to the "scope is synonymous with dictionary attached to some object" idea or maybe it would have required a dictionary to be attached to a case statement. I personally think local scope should have been viewed as a hard requirement if they were to introduce this to the language.
    - pfalcon 6y ago
      Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
      - CogitoCogito 6y ago
        I'm interested in sane semantics. In this case, that calls for block-level scoping. Those who introduced pattern matching should have understood that the lack of block-level scoping _before_ this PEP does in no way support the continuing of the status quo. The language after this PEP has changed and has turned into one where block-level scoping is appropriate in this case. I'm honestly _not_ interested in block-level scoping in this case because I would _never_ have wanted this PEP to be accepted. This feature was quite controversial on the various python mailing lists, and yet the steering committee accepted it anyway. The steering committee might consider leading with a bit more humility and _not_ accepting such controversial PEPs. This is an example of language devolution and not evolution.
dragonwriter 6y ago
> This is how pattern matching works in any language No, its not, but no language (at least that I am aware of) except python does pattern matching + local variables + not introducing a new scope with the pattern match. Ruby is the closest, but it does introduce a new scope while providing a mechanism for binding variables in the containing local scope. (As well as a method to “pin” variables from the containing scope to use them in matches.)
- _nosewings_ 6y ago
  Not introducing a new scope with a match is unfortunate, but it's also consistent with how every other language feature interacts with scoping. > (As well as a method to “pin” variables from the containing scope to use them in matches.) This is a good idea, I agree -- at least for Python, where you would obviously just call __eq__. EDIT: It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me.
  - dragonwriter 6y ago
    > Not introducing a new scope with a match is unfortunate, but it's also consistent with how every other language feature interacts with scoping. Except comprehensions, which changed in Py 3 to have their own scope, rather than binding control variables in the surrounding (function or module) scope as in Py 2. > It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me. It would be except: * You can't access function-scoped identifiers that way. * You can't access module-scoped identifiers in the main module that way. * You can't conveniently reference identifiers in the current module that way. (I think you can use the full module path to qualify the name in the local module, but that's both awkward and brittle to refactoring, and there's pretty much never a reason to do it for any other purpose.)
- pfalcon 6y ago
  Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
coldtea 6y ago
>Many of the comments here reveal a bizarre parochialism. This seems like a bizarre misunderstanding of Python scoping rules, and how this can be a problem here.

This is how pattern matching works in any language (except for some niche languages that allow nonlinear patterns, like Curry). Many of the comments here reveal a bizarre parochialism.

pansa2 6y ago

In that case, what’s the correct way to write a clause that only matches if `status` is equal to 404? Do we have to use the integer literal 404 instead of a named integer?

_nosewings_ 6y ago
Yes, of course. Again, this is how it works in basically every mainstream language with this feature.
- pansa2 6y ago
  Really? It’s best practice to use a magic number rather than a name? That breaks one of the most fundamental rules for writing good code.
  - _nosewings_ 6y ago
    If you really need to compare against a variable, use an "if". The primary benefit of pattern-matching is destructuring. EDIT: It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me.
    - hnlmorg 6y ago
      No it’s not because it’s none obvious and requires a fair amount of boilerplate code. Both of which are usually idioms Python normally tries to avoid. I guarantee you this will trip up a lot of developers who are either learning the language for the first time or who Python isn’t their primary language. Worse still, the kind of bugs this will lead to is valid code with unexpected pattern matching, which is a lot harder to debug than invalid code which gets kicked out with a compiler error.
- mannerheim 6y ago
  There are PatternSynonyms in Haskell.
ben509 6y ago
It will be to stick your constants in a module and use module.constant to match them. Or use an enum. Or hang them off a class.

chriswarbo 6y ago

Not the scoping rule. For example, in Haskell: let x = foo in ( case bar of x -> x, x ) This will give `(bar, foo)`: for the first element the `x` in the case will match against `bar` and return it, then that `x` will be discarded as we leave its scope; the second element uses the binding of `x` in the `let`. According to the Python semantics we would get `(bar, bar)`, since we only have one `x` variable. When the case pattern succeeds, the existing `x` is updated to refer to `bar`. Hence we get the `bar` we expect in the first element, but we also get `bar` as the second element, since that `x` variable was updated. (Note that Python guarantees that tuple elements are evaluated from left to right).

_nosewings_ 6y ago
That's just an inevitable consequence of the fact that, in Python, "scope" is synonymous with "dictionary attached to some object." This is already how for-loops work.
- CogitoCogito 6y ago
  It's not "inevitable". They could have required local variables in case statements to be local to that case statement. It would have required changes to the "scope is synonymous with dictionary attached to some object" idea or maybe it would have required a dictionary to be attached to a case statement. I personally think local scope should have been viewed as a hard requirement if they were to introduce this to the language.
  - pfalcon 6y ago
    Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.
    - CogitoCogito 6y ago
      I'm interested in sane semantics. In this case, that calls for block-level scoping. Those who introduced pattern matching should have understood that the lack of block-level scoping _before_ this PEP does in no way support the continuing of the status quo. The language after this PEP has changed and has turned into one where block-level scoping is appropriate in this case. I'm honestly _not_ interested in block-level scoping in this case because I would _never_ have wanted this PEP to be accepted. This feature was quite controversial on the various python mailing lists, and yet the steering committee accepted it anyway. The steering committee might consider leading with a bit more humility and _not_ accepting such controversial PEPs. This is an example of language devolution and not evolution.

dragonwriter 6y ago

> This is how pattern matching works in any language No, its not, but no language (at least that I am aware of) except python does pattern matching + local variables + not introducing a new scope with the pattern match. Ruby is the closest, but it does introduce a new scope while providing a mechanism for binding variables in the containing local scope. (As well as a method to “pin” variables from the containing scope to use them in matches.)

_nosewings_ 6y ago
Not introducing a new scope with a match is unfortunate, but it's also consistent with how every other language feature interacts with scoping. > (As well as a method to “pin” variables from the containing scope to use them in matches.) This is a good idea, I agree -- at least for Python, where you would obviously just call __eq__. EDIT: It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me.
- dragonwriter 6y ago
  > Not introducing a new scope with a match is unfortunate, but it's also consistent with how every other language feature interacts with scoping. Except comprehensions, which changed in Py 3 to have their own scope, rather than binding control variables in the surrounding (function or module) scope as in Py 2. > It looks like you actually can match against constants with this PEP, as long as you access your constant with a dot (e.g., HttpError.NotFound). This seems like a perfectly reasonable solution to me. It would be except: * You can't access function-scoped identifiers that way. * You can't access module-scoped identifiers in the main module that way. * You can't conveniently reference identifiers in the current module that way. (I think you can use the full module path to qualify the name in the local module, but that's both awkward and brittle to refactoring, and there's pretty much never a reason to do it for any other purpose.)
pfalcon 6y ago
Interested in block-level scoping in Python? Please post on the python-ideas mailing list. Thanks.

coldtea 6y ago

>Many of the comments here reveal a bizarre parochialism. This seems like a bizarre misunderstanding of Python scoping rules, and how this can be a problem here.