Hacker News Reader

Comment by AlexandrB | Hacker News Reader

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.

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.

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).

... except in case expressions

Thanks for proving my point though!

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))

    ...
    case Click(position=(x, y))

those identical expressions, for the same value of Click, have widely different semantics?

edit: typo fix

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`

Reply on news.ycombinator.com