Comment by vlade11115

Comment by vlade11115 3 days ago

7 replies

While the article is very entertaining, I'm not a fan of the pattern matching in Python. I wish for some linter rule that can forbid the usage of pattern matching.

siddboots 3 days ago

Can you explain why? Genuinely curious as a lover of case/match. My only complaint is that it is not general enough.

  • kurtis_reed 3 days ago

    Double indentation

    • maleldil 2 days ago

      So? Other languages with pattern match similarly have such double indentation. C-style switch with unintended cases is weird.

jbmchuck 3 days ago

Should be easily doable with a semgrep rule, e.g.:

    ~> cat semgrep.yaml
    rules:
      - id: no-pattern-matching
        pattern: |
          match ...:
        message: |
          I'm not a fan of the pattern matching in Python
        severity: ERROR
        languages:
          - python
...

    ~> cat test.py
    #!/usr/bin/env python3

    foo = 1
    match foo:
      case 1:
        print("one")
...

    ~> semgrep --config semgrep.yaml test.py   


     no-pattern-matching
          I'm not a fan of the pattern matching in Python
                                                         
            4┆ match foo:
            5┆   case 1:
            6┆     print("one")
(exits non-0)
  • PokestarFan 3 days ago

    You need to make that exclude match = ... since match can also be a variable name. This is because people used to write code like match = re.search(...)

    • TheDong 3 days ago

      The existing pattern suggested above, "match ...:", will not match 'match = ...'.

      Presumably the reason the parent comment suggested semgrep, not just a grep, is because they're aware that naive substring matching would be wrong.

      You could use the playground to check your understanding before implying someone is an idiot.

      https://semgrep.dev/playground/new

smcl 3 days ago

If you're experienced enough with Python to say "I want to eliminate pattern matching from my codebase" you can surely construct that as a pre-commit check, no?