
On 2021-10-27 at 13:47:31 +1100, Chris Angelico <rosuav@gmail.com> wrote:
On Wed, Oct 27, 2021 at 1:15 PM Brendan Barnwell <brenbarn@brenbarn.net> wrote:
On 2021-10-26 17:41, Christopher Barker wrote:
Python used to be such a simple language, not so much anymore :-(
I quite agree, and I feel like this is my biggest reason why I don't want this "feature" (or any of another gazillion features that have been suggested and/or accepted here, including the walrus). The benefit of this PEP simply does not justify the added complexity of the language as a whole. Using None (or some sentinel) and including code to check for it works fine. It's not worth it to add a whole new layer of behavior to something as basic as argument-passing just to avoid having to type `if arg is None`.
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.
[...]
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 agree. Why do we need the ability to put "lo=0" in the signature? If we have to rewrite parts of bisect_right for late binding anyway, then why not go all out? If you want to bisect a slice, then bisect a slice: result = bisect_right(a[lo:hi], x) Oh, wait, what if a has billions of elements and creating a slice containing a million or two out of the middle is too expensive? Then provide two functions: def bisect_right(a, x, key=None): return bisect_slice_right(a, x, 0, len(a), key) def bisect_slice_right(a, x, lo, hi, key=None): "actual guts of bisect function go here" "don't actually slice a; that might be really expensive" No extraneous logic to (re)compute default values at all. Probably fewer/simpler units tests, too, but that might depend on the programmer or other organizational considerations. On the other side, parts of doc strings may end up being duplicated, and flat is better than nested. (No, I don't know the backwards compatibility issues that might arise from re-writing bisect_right in this manner, nor do I know what the options are to satisfy IDEs and/or users thereof.) Running with Brandon Barnwell's point, is there a lot of code that gets a lot simpler (and who gets to define "simpler"?) with late binding default values? Can that same code achieve the same outcome by being refactored the same way as I did bisect_right? I'm willing to accept that my revised bisect_right is horrible by some reasonably objective standard, too.