Hacker News Reader

Comment by utborin | Hacker News Reader

Oh, yikes. I understand what's happening here but this is going to bite a lot of people.

I might be misreading the grammar but it looks like you can produce the desired effect by using an attribute, e.g. the following would perform an equality check, not an assignment:

  match status:
      case requests.codes.not_found:
          return "Not found"

The tutorial seems to confirm this: "This will work with any dotted name (like math.pi). However an unqualified name (i.e. a bare name with no dots) will be always interpreted as a capture pattern"

View on HN

The inconsistency just makes it worse and will lead to even more bugs. I foresee lint rules prohibiting match statements in the near future.

Couldn't they have used "case" and "capture" clauses instead?

  match status:
     case not_found:
         return "Not found"
     capture success_code:
         return "Returned success code: %s" % success_code

or the "_ as x" or a myriad other ways to make capture explicit...

A separate statement doesn't compose with complex patterns. I'd prefer always requiring the walrus operator to capture:

    match response:
      case (not_found, msg := _):
        return f"Not found: {msg}"
      case (error, "No swizzle available"):
        return "We lack swizzle. :-("
      case pair := (_, "Swizzle"):
        log(f"Unexpected swizzle: {pair}")
        return f"Swizzle?"
      case ((code := _), _):
        return f"Success: {code}"

Yes, apparently your example will work correctly.

Now think what will happen if you need to move that not_found variable to the same file as that code (so it will no longer be a dotted name). If you do it manually you need to be extra careful, if you use an automatic tool either it will reject the change or will need to create a dummy class or something in the process.

Reply on news.ycombinator.com