On Wed, Dec 1, 2021 at 8:57 PM Neil Girdhar <mistersh...@gmail.com> wrote: > > > > On Wednesday, December 1, 2021 at 1:18:33 AM UTC-5 Chris Angelico wrote: >> >> I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ >> with some additional information about the reference implementation, >> and some clarifications elsewhere. >> >> *PEP 671: Syntax for late-bound function argument defaults* >> >> Questions, for you all: >> >> 1) If this feature existed in Python 3.11 exactly as described, would >> you use it? > > No, I would avoid for the sake of readers. Anyway, it can't be used in any > public projects until thy drop support for 3.10, which is many years off. > > Also, I think this question is quite the biased sample on python-ideas. > Please consider asking this to less advanced python users, e.g., > reddit.com/r/python or learnpython.
I know it is :) I never expected to get an unbiased sample (from anywhere, least of all here). > This PEP has a lot of interesting ideas. I still think that none-aware > operators (PEP 505) are an easier, more readable general solution to binding > calculated default values to arguments succinctly. I think the problems with > this idea include: > * The caller cannot explicitly ask for default behaviour except by omitting > the parameter. This can be very annoying to set up when the parameter values > are provided from other places, e.g., > if need_x: > # do lots of stuff > x = whatever > else: > # do more > x = None > f(x=x, ...) # easy, but with this PEP, you would have to find a way to > remove x from the parameter list. Typically, removing a parameter from a > dynamically-created parameter list is hard. > You can always do that with *args or **kwargs if that's what you need, and that actually DOES represent the concept of "don't pass this argument". Passing None is a hack that doesn't actually mean "don't pass this argument", and if you're depending on that behaviour, it's been locked in as the function's API, which causes problems if None ever becomes a meaningful non-default value. None-aware operators are solving a different problem. They allow you to accept None, but then simplify the replacement of it with some other value. This proposal allows you to leave None out of the equation altogether. And it only works if None isn't a valid value. > * The function code becomes unreadable if the parameter-setting code is long. > Having a long piece of code inside the function after "if parameter is None" > is just fine. Having none-aware operators would make such code more succinct. > Again, that only works if None is not a valid parameter value, and PEP 505 doesn't generalize to other sentinels at all. If the code is too long, don't put it into the parameter default. But "if x is None: x = []" can easily be replaced with "x=>[]" and the parameters will actually become shorter. ANY feature can be used badly. You can daisy-chain everything into a gigantic expression with horrendous abuses of lambda functions, but that doesn't mean you should. It also doesn't mean that lambda functions are bad :) > * People nearly always avoid writing code in the parameter defaults > themselves, and this new practice adds a lot of cognitive load. E.g., people > rarely write: > def f(x: int = 1+g()) -> None: ... > Parameter lists are already busy enough with parameter names, annotations, > and defaults. We don't need to encourage this practice. > They don't become any more noisy by being able to use defaults that aren't constant. The main goal is to put the function header in the function header, and the function body in the function body, instead of having the function body doing part of the work of the header :) > In short, I think this is a creative idea, a great exploration. While > optional parameters are common, and some of them have defaults that are > calculated inside the function, my feeling is that people will continue to > set their values inside the function. > In some cases, they certainly will. And that's not a problem. But for the cases where it's better to put it in the header, it's better to have that option than to restrict it for an arbitrary technical limitation. Some languages don't have ANY function defaults. They simply have "optional arguments", where an omitted optional argument will always and only have a specific null value. Python allows you to show what the default REALLY is, and that's an improvement. I want to be able to show what the default is, even if that is defined in a non-constant way. ChrisA _______________________________________________ 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/23E62MLZH3ZMRYWTYPXDKG2LWT6X3G2V/ Code of Conduct: http://python.org/psf/codeofconduct/
