On Tue, Oct 26, 2021 at 8:29 PM Ethan Furman <[email protected]> wrote:

> Using the `bisect()` function as a stand-in for the 20+ years worth of
> Python APIs in existence:
>
>      def bisect_right(a, x, lo=0, hi=None, *, key=None):
>          if hi is None:
>              hi = len(a)
>          while lo < hi:
>              ...
>
> That function would be transformed to:
>
>      def bisect_right(a, x, lo=0, @hi=len(a), *, key=None):
>          if hi is None:
>              hi = len(a)
>          while lo < hi:
>


> Notice that the `None` check is still in the body -- why?  Backwards
> compatibility:


Of course. personally, I don't think there's any reason to go in and change
the standard library at all.

This is a feature for new code, new APIs. *maybe* a long time from now,
some stdlib APIs could be updated, but no hurry.

This seems like a lot of effort for a very marginal gain.
>

marginal gain to the stdlib, yes of course.

Though now that you mention it -- there would be some marginal game even to
functions like that, making the function signature a bit more clear.

Interestingly, though, here's bisect's docstring:

In [14]: bisect.bisect?
Docstring:
bisect_right(a, x[, lo[, hi]]) -> index

Return the index where to insert item x in list a, assuming a is sorted.

The return value i is such that all e in a[:i] have e <= x, and all e in
a[i:] have e > x.  So if x already appears in the list, i points just
beyond the rightmost x already there

Optional args lo (default 0) and hi (default len(a)) bound the
slice of a to be searched.
Type:      builtin_function_or_method

It's not actually documented that None indicates "use the default".

Which, it turns out is because it doesn't :-)

In [24]: bisect.bisect([1,3,4,6,8,9], 5, hi=None)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-24-65fd10e3a3b5> in <module>
----> 1 bisect.bisect([1,3,4,6,8,9], 5, hi=None)

TypeError: 'NoneType' object cannot be interpreted as an integer

I guess that's because in C there is a way to define optional other than
using a sentinel? or it's using an undocumented sentinal?

Note: that's python 3.8 -- I can't imagine anything;s changed, but ...

-CHB

-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/NUYBMMBIEHLLIJL6M36OKIGWI3E5DIBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to