On 2021-10-23 09:07, Chris Angelico wrote:
Proposal: Proper syntax and support for late-bound argument defaults.
def spaminate(thing, count=:thing.getdefault()): ...
I'm -1 on it. For me the biggest problem with this idea is that it only handles a subset of cases, namely those that can be expressed as an expression inlined into the function definition. This subset is too small, because we'll still have to write code in the function body for cases where the default depends on more complex logic. But it is also too large, because it will encourage people to cram complex expressions into the function definition. To me, this is definitely not worth adding special syntax for. I seem to be the only person around here who detests "ASCII art" "arrow" operators but, well, I do, and I'd hate to see them used for this. The colon or alternatives like ? or @ are less offensive but still too inscrutable to be used for something that can already be handled in a more explicit way. I do have one other specific objection to the rationale:
It's clear what value lo gets if you omit it. It's less clear what hi gets. And the situation only gets uglier if None is a valid argument, and a unique sentinel is needed; this standard idiom makes help() rather unhelpful:
Not really. help() shows the *documentation* of the function. A person calling it should *read the documentation*, not just glance at the function signature. I don't see any compelling benefit to having a mini-lambda be retrievable via introspection tools. There is simply no substitute for actually reading (and writing) the documentation. Also, insofar as glancing at the function signature is useful, I suspect that putting this change in will *also* lead to help() being unhelpful, because, as I mentioned above, if the default uses anything but the most trivial logic, the signature will become cluttered with stuff that ought to be separated out as actual logic. I would prefer to see this situation handled as part of a larger-scale change of adding some kind of "inline lambda" which executes directly in the calling scope. (I think this is similar to the "deferred computation" idea mentioned by David Mertz elsewhere in the thread.) This would also allow extracting the logic out of the function definition into a separate variable (holding the "inline lambda"), which could help with cases similar to the bisect examples discussed elsewhere in the thread, where multiple functions share late-binding logic. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown