Steven D'Aprano writes:
The match...case statement didn't "need" keywords either, we could have picked symbols instead if we wanted to look like APL. Remember that keywords have advantages as well as disadvantages. Given the existence of community support for keywords, the PEP should make the case that symbols are better in this case.
The argument I would make is that in the presence of type annotations a keyword adds a lot of verbosity, and is possibly confusable (ie, ignorable) as a type component, and that that is sufficient argument for a symbol rather than a keyword.
This raises another choice: should lazy defaults be evaluated before entering the body of the function, or at the point where the parameter is used? Which would be more useful?
<img src=both_both_both.gif/> Chris makes the point that we've been through this before so I won't belabor that point. Both are potentially useful. Chris wants syntax for the common pattern def foo(arg_with_new_empty_list_default=None): if arg_with_new_empty_list_default is None: arg_with_new_empty_list_default = [] # do stuff and variants (eg, where the default is a computation expensive enough that you don't want to do it if the argument is never defaulted). I don't find that burdensome enough to want syntax, and I can't guess how quickly I'd start using it if available, that probably depends on how often the community seems to be using it (ie, in the code I'm reading). I can't really guess how useful the "use point" version would be. It's not a pattern I've used, I use a zero-argument function very occasionally but I can't recall a case where I used a lambda (lambdas are kinda annoying). Adding the parens at the call is easy to forget, but not that huge a burden either. The only use case I can think of offhand is where the default is such an expensive computation that you don't want it done unless its result is actually used, and it might not be: def foo(flag, arg=None, *otherargs): if flag: if arg is None: arg = expensive_function return arg(*other_args) else: return a_constant On the one hand, it seems likely that a very expensive function is expensive enough to avoid at the cost of an obscure default and an if in the definition of foo. On the other the whole scenario seems rather contrived and not worth syntax.