
On 2021-10-30 15:35, Chris Angelico wrote:
Bear in mind that the status quo is, quite honestly, a form of white lie. In the example of bisect:
def bisect(a, hi=None): ... def bisect(a, hi=>len(a)): ...
neither form of the signature will actually say that the default value is the length of a. In fact, I have never said that the consumer should eval it. There is fundamentally no way to determine the true default value for hi without first figuring out what a is.
The way you use the term "default value" doesn't quite work for me. More and more I think that part of the issue here is that "hi=>len(a)" we aren't providing a default value at all. What we're providing is default *code*. To me a "value" is something that you can assign to a variable, and current (aka "early bound") argument defaults are that. But these new late-bound arguments aren't really default "values", they're code that is run under certain circumstances. If we want to make them values, we need to define "evaluate len(a) later" as some kind of first-class value.
So which is better: to have the value None, or to have a marker saying "this will be calculated later, and here's a human-readable description: len(a)"?
Let me say that in a different way. . . :-) Which is better, to have a marker saying "this will be calculated later", or to have a marker saying "this will be calculated later, and here's a human-readable description"? My point is that None is already a marker. It's true it's not a special-purpose marker meaning "this will be calculated later", but I think in practice it is a marker that says "be sure to read the documentation to understand what passing None will do here". Increasingly it seems to me as if you are placing inordinate weight on the idea that the benefit of default arguments is providing a "human readable" description in the default help() and so on. And, to be frank, I just don't care about that. We can already provide human-readable descriptions in documentation and we should do that instead of trying to create gimped human-readable descriptions that only work in special cases. Or, to put it even more bluntly, from my perspective, having help() show something maybe sort of useful just in the case where the person wrote very simple default-argument logic and didn't take the time to write a real docstring is simply not a worthwhile goal. So really the status quo is "you can already have the human-readable description but you have to type it in the docstring yourself". I don't see that as a big deal. So yes, the status quo is better, because it is not really any worse, and it avoids the complications that are arising in this thread (i.e., what order are the arguments evaluated in, can they reference each other, what symbol do we use, how do we implement it without affecting existing introspection, etc.). -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown