Sascha Desch

```python match x: case True: ... case 1: ... case 1.0: ... ``` would work intuitively if the check for literals were `isinstance(x, type(literal)) and x == literal`. ```python def...

@gvanrossum Proposing that `is` should be used instead of `==` for `True` and `False` is actually why I first opened the thread and I agree that this solves most of...

> if I pass say a `numpy.float64(1.0)`, I'd probably expect it to match `1.0`, but it's a different type. @JelleZijlstra Actually `numpy.float64(1.0)` would match `case 1.0` since `issubclass(numpy.float64, float)` is...

@JelleZijlstra yeah I just noticed that `numpy.float16(1.0)` would not match `case 1.0` which I'd think might actually be a feature since someone who goes to the length of using numpy...

@gvanrossum Another argument **against** using the numeric tower would be that `match` is conceptually much more about destructuring objects and dispatching on types than about comparing values i.e. *switch-case* semantics....

I totally forgot about PEP 484 considering `int` a subtype of `float` and you are of course right that the distinction between `1` and `1.0` does not matter much in...

curious question: would the parser be able to distinguish `float(42.0)` and `42.0`? Then if someone wanted to be really pedantic about their floats and ints one might be able to...

@brandtbucher I didn't know that; thanks a lot. Using that syntax it's possible to write ``` match x: case bool(True):... case int(1): ... case float(1.0): ... ``` however the issue...

I though about something like json-serialization e.g. ``` def encode(value): match value: case None: return 'null' case bool(x): return str(x).lower() case str(x): return x case int(x) | float(x): return x...

> maybe this example, trivial as it is, [...] it actually isn't all that trivial since there are also `float('-inf')`, `float('inf')` and `float('nan')` the first two don't currently appear to...