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