On 2021-10-26 19:47, Chris Angelico wrote:
help(bisect.bisect)
bisect_right(a, x, lo=0, hi=None, *, key=None)
...
Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.
In the docstring, both lo and hi are given useful, meaningful
defaults. In the machine-readable signature, which is also what would
be used for tab completion or other tools, lo gets a very useful
default, but hi gets a default of None.
How would tab completion work with this new feature? How could a
late-bound default be tab-completed? Usually when I've used
tab-completion with function arguments it's only completing the argument
name, not the default value.
For the key argument, None makes a very meaningful default; it means
that no transformation is done. But in the case of hi, the default
really and truly is len(a), but because of a technical limitation,
that can't be written that way.
Here is some code:
def foo():
for a in x:
print(a)
for b in x:
print(b)
other_func(foo)
Due to a technical limitation, I cannot write foo as a lambda
to pass it inline as an argument to foo. Is this also a problem? If
so, should we develop the ever-whispered-about multiline lambda syntax?
Yes, there are some kinds of default behaviors that cannot be
syntactically written inline in the function signature. I don't see
that as a huge problem. The fact that you want to write `len(a)` in
such a case is not, for me, sufficient justification for all the other
cans of worms opened by this proposal (as seen in various subthreads on
this list), to say nothing of the additional burden on learners or on
readers of code who now must add this to their list of things they have
to grok when reading code.
Suppose this function were written as:
bisect_right(a, x, lo=None, hi=None, *, key=None)
Do we really need the ability to specify actual function defaults? I
mean, you can just have a single line of code "if lo is None: lo = 0"
and it'd be fine. Why do we need the ability to put "lo=0" in the
signature? I put it to you that the same justification should be valid
for hi.
I understand what you're saying, but I just don't agree. For one
thing, functions are written once and called many times. Normal default
arguments provide a major leverage effect: a single default argument
value can simplify many calls to the function from many call sites,
because you can (potentially) omit certain arguments at every call.
Late-bound defaults provide no additional simplicity at the call sites;
all they do is permit a more terse spelling at the function definition
site. Since the definition only has to be written once, a bit more
verbosity there is not so much of a burden.
Also, the attempt to squeeze both kinds of defaults into the signature
breaks the clear and simple rule we have, which is that the signature
line is completely evaluated right away (i.e., it is part of the
enclosing scope). Right now we have a clean separation between the
function definition and the body, which this proposal will muddy quite
profoundly. The problem is exacerbated by the proposed syntaxes, nearly
all of which I find ugly to varying degrees. But I think even with the
best syntax, the underlying problem remains that switching back and
forth between definition-scope and body-scope within the signature is
confusing.
Finally, I think a big problem with the proposal for me is that it
really only targets what I see as a quite special case, which is
late-bound expressions that are small enough to readably fit in the
argument list. All of the arguments (har har) about readability go out
the window if people start putting anything complex in there. Similarly
if there is any more complex logic required (such as combinations of
arguments whose defaults are interdependent in nontrivial ways) that
cannot easily be expressed in separable argument defaults, we're still
going to have to do it in the function body anyway. So we are adding an
entirely new complication to the basic argument syntax just to handle
(what I see as) a quite narrow range of expressions.
--
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/X3OO4KV4GSJ5CV7OCEZRZAAY7Z2T6V55/
Code of Conduct: http://python.org/psf/codeofconduct/
