Abdulla Al Kathiri writes:
case def fib(0): return 0
This syntax (1) is a new, slightly shorter version of something we can already do as you point out yourself, and (2) plausibly is something of a bug magnet if someone does
case def fib(1): case def fib(2): def fib(n):
Plausible != probable, but given Python's general conservatism vs. syntax, I suspect "this bug is improbable" is on you to argue.
Notes: These comments are not original to me. I do agree that this is a plausible syntax, and don't agree with Steven d'A's suggestion that it might be offputting to new Pythonistas -- I think it could go either way if implemented. I just don't think it's particularly Pythonic or beneficial to Python, so -1.
If you none of the parameters you pass match your case functions, an exception will be raised. Maybe it would be easier to make those functions faster since we already know the types in advance.
This claim needs to be supported, and it kinda seems unlikely since we already have
def fib(n : int) -> int:
(although the optimizer doesn't use such information yet AFAIK).
def fib(n): case 0, : return 0 case 1, : return 1 case int(n), : return fib(n-1) + fib(n-2)
As opposed to …
def fib(*args): match args: case 0, : return 0 case 1, : return 1 case int(n), : return fib(n-1) + fib(n-2)
Saving one line and one level of indentation doesn't seem worth new syntax. This kind of claim is easy to address (again, given Python's conservatism I think it's on the proponents, not the opponents) by going through the stdlib or some other large codebase (Numpy or Pandas or requests might be good candidates) and showing that in fact such dispatching styles would likely bleed off the right edge in many cases where the project has a tight column limit (such as Python's 79 column convention, which is much tighter than many Python programmers like).
By the way, what's with the rather strange syntax? In Python 3.10rc1,
def fib(n): match n: case 0: return 0 case 1: return 1 case n if isinstance(n, int) and n > 1: return fib(n-1) + fib(n-2) case _: raise RuntimeError
is how I'd write it, although I'm not sure that reusing 'n' that way is good style (and RuntimeError is the wrong exception but I'm too lazy to look up the right spelling for args-out-of-range in Python).
Interestingly, I can't find a definition for n that gets fib(1.0) to error, except by prepending a "case float()". Not sure if that is intended, anybody know?