3 ms·

Yup, that's what the PEP seems to suggest. This along with mutable default values is going to be one of the nastier Python warts.

• toxik 6y ago
  Not to mention that expressions after the case keyword have completely different semantics from expressions ANYWHERE else. a | b is not the bitwise or of a with b.
  • vitus 6y ago
    You can already define __or__ to do whatever you want! This is already special-cased in the standard library for, say, set union (where admittedly the concept is more similar to bitwise or).
    • toxik 6y ago
      ... except in case expressions Thanks for proving my point though!
  • amirkdv 6y ago
    This part is truly strange. This example from the tutorial drove it home for me: match event.get(): case Click(position=(x, y)): handle_click_at(x, y) case KeyPress(key_name="Q") | Quit(): game.quit() where `Click(position=(x, y))` is not at all what one would expect. What I still don't understand is: does the new syntax magically do this to a user-defined class? i.e. if I say foo = Click(position=(x, y)) vs ... case Click(position=(x, y)) those identical expressions, for the same value of Click, have widely different semantics? edit: typo fix
    • bobbylarrybobby 6y ago
      You are (sadly) correct. The latter example checks that the type of `event.get()` is a Click, then that it has a `.position` attribute that be restructured into a two-element tuple `(x,y)`. It's equivalent to `ev = event.get(); if isinstance(ev, Click): (x,y) = ev.position`