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.
_______________________________________________
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/6Z7GD6STJQP7ABKINIMBNCVBS4BOSLOG/
Code of Conduct: http://python.org/psf/codeofconduct/
