Merge bisect

[tharvik]

https://docs.python.org/3/library/bisect.html

[matthiaskramm]

It's perfectly legal for x to not be in a.

For example,

bisect.bisect_left([1,2,3], None)

is valid code. (And bisect_left will just return 0 in this case)

So the type parameter here is overkill.

[gvanrossum]

That seems a 2/3 difference though -- in PY3 None < 1 is a TypeError.

[matthiaskramm]

But even Python 3 allows

bisect.bisect_left([1, 2, 3], 5.391)

which is still a type error for

def bisect_left(a: Sequence[_T], x: _T)

[gvanrossum]

But do you have code that relies on that? Usually a bisect() call is followed by an insert() at the found position, and inserting 5.391 into a List[int] is a type error. So I still prefer the PR as-is here rather than the original object.

[matthiaskramm]

test_bisect.py itself is doing bisect_left([1, 2, 3], 1.5) for testing.

In pysco, I found the little gem

i = bisect.bisect(codeboundary, (self.addr-0.5, self))`

In our codebase, I'm also seeing a few occurences of the pattern bisect(seq, (low + high) * 0.5), presumably for getting some kind of percentiles.

I know it's tempting to use typeshed to define APIs the way we think they should be used, rather than how people are currently using them. But let's resist that and model the real world.

[JukkaL]

Hmm I think that bisect.bisect_left([1, 2, 3], 5.391) should be okay even if the definition is like this:

def bisect_left(a: Sequence[_T], x: _T) -> int: ...

Since int gets promoted to float, we'd infer _T = float. And as sequence is covariant, List[int] is compatible with Sequence[float].

[matthiaskramm]

Tried your suggestion in mypy, but got:

Cannot infer type argument 1 of "bisect_left"

[JukkaL]

That looks like a mypy bug to me (filed python/mypy#2035).

[gvanrossum]

The mypy bug won't be fixed soon (it's a bit tricky). Can you either put a # type: ignore on the line or use Any for the type of x?

[tharvik]

Gone for a TODO and using Any.