All good points. To me there is an elegance in being able to split the
different paths of the function into their own syntactically separate
function definitions.
One place where this excels is in handling happy paths vs error paths.
It increases clarity substantially, in my experience, to be able to code
the happy path without separately from the error path.
```
def foo("error")
# do some error handling
def foo(n):
# code the happy path
```
Whether this is worth the extra syntax, as you put it, I'm not sure.
I don't think I have the knowledge to write a PEP that has a reasonable
chance of adoption, so at this point I'm just "offering the idea".
On 05/08/2021 10:24, Paul Moore wrote:
> I assume that such a feature would simply behave exactly the same as a
> match statement:
>
> def fib(arg):
> match arg:
> case 0:
> return 0
> case 1:
> return 1
> case n:
> return fib(n-1) + fib(n-2)
> # I know this is only a trivial example,
> # but you should probably also handle
> # n < 0. Does your proposal cover using
> # guards, or would they need a conditional
> # in the final case?
>
> def allow_entry(arg):
> match arg:
> case {"name": "Bob"}:
> return "Bob is not allowed in ever!"
> case {"name": "Charles", "day": "Tuesday"}:
> return "It's a Tuesday, so Charles is allowed in."
> case {"name": "Charles", "day": _}:
> return "Charles is only allowed in on a Tuesday."
> case {"name": name}:
> return f"Come in {name}, make yourself at home!"
> # I only skimmed the PEP, and I don't have a copy of Python 3.10 to check,
> # but I believe that if arg doesn't match any of the given
> clauses, the match
> # silently does nothing. I don't know if that was your expected
> behaviour for
> # the definition form, but you should probably be explicit about
> what you intend
> # in any case.
>
> Note that I created these by taking your examples and applying a
> purely mechanical translation - I didn't think about it at all, so
> this transformation could easily be applied mechanically. What's the
> benefit that would justify having this additional syntax?
>
> In addition, you'd need to consider the implications of possibilities
> you didn't cover in your examples. I don't know Elixir, so I can't say
> whether that language has similar scenarios that we could follow, but
> these are all valid in Python, so we need to consider them.
>
> Python's function definitions are executed at runtime, so you need to
> decide what behaviour you want from a function definition that's had
> *some* of its parts executed, but not others. So how would the
> following behave?
>
> def example(1):
> return "One"
>
> print(example(2))
>
> def example(2):
> return "Two"
>
> print(example(2))
>
> Worse, what if the example(2) definition were in a separate module?
>
> What about decorators?
>
> def example(1):
> return "One"
>
> @some_decorator
> def example(2):
> return "Two"
>
> That's just a very brief list of "things to think about". In
> functional languages, I like this style of function definition, but it
> would need some fairly careful design to be able to translate it to a
> language like Python. And honestly, I'm not sure I see the advantage
> (in Python).
>
> I'm not against the suggestion as such, but I think it will need a
> fair amount of work to flesh it out from a series of basic examples to
> a full-fledged proposal (which even then might end up getting
> rejected). Is that something you're considering doing yourself, or are
> you just offering the idea in case someone else is interested in
> picking it up?
>
> Paul
>
> On Thu, 5 Aug 2021 at 09:52, Sam Frances wrote:
>>
>> Following on from PEP 634, it would be good to be able to have Erlang /
>> Elixir-style pattern matching in function headers.
>>
>> (I don't know what the technical term is for this language feature, but
>> hopefully the examples will clarify.)
>>
>> Here's the obligatory fibonacci example:
>>
>> ```
>> def fib(0):
>> return 0
>>
>> def fib(1):
>> return 1
>>
>> def fib(n):
>> return fib(n-1) + fib(n-2)
>> ```
>>
>> Or, another example:
>>
>> ```
>> def allow_entry({"name": "Bob&
