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?
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/3M3IUZFMZBPISDAMOKSW4M7R367R6ZSR/
Code of Conduct: http://python.org/psf/codeofconduct/
