This protocol corresponds to what is called "hash object" in the hashlib documentation. In particular, it includes the non-OpenSSL BLAKE2 implementations which do not inherit HASH.
This reverts commit 57d7c4334b.
The attempted fix loses all type overload information during type
inferencing, so postpone fixing the issue until we have a solution
which doesn't impose such a dramatic loss in functionality.
Reopens#13403
The `chr` function does accept objects that implement the
`SupportsIndex` protocol. The [implementation] of the builtin method
calls `PyLong_AsLongAndOverflow` on the argument, which in turn calls
`__index__()`, if present. The parameter of the `chr` function can
therefore be annotated with `int | SupportsIndex`.
It seems to me like `SupportsIndex` alone would be enough, since `int`
implements `SupportIndex`, but I chose `int | SupportIndex` to make it
consistent with the annotations on `hex`, `oct` and `bin`.
[implementation]: https://github.com/python/cpython/blob/b05fa90b21dd01bb836285cdd41920320b09e681/Python/bltinmodule.c#L725
[PyLong_AsLongAndOverflow]: https://docs.python.org/3.13/c-api/long.html#c.PyLong_AsLongAndOverflow
```python
def format_stack_entry(self, frame_lineno, lprefix=': '):
...
frame, lineno = frame_lineno
```
The type of `frame_lineno` is `tuple[FrameType, int]` not `int`,
understandably, since the type of `frame_lineno` can be interprted as
the line number of the frame. But looking at the implementation of
`Bdb.format_stack_entry`, it is clear that `frame_lineno` is a tuple.
It is also necessary to somehow pass a frame to `format_stack_entry` if
we want it to be formatted...
The answer to the question is that mypy infers it just fine, but
stubtest doesn't check for attributes inherited from the metaclass
because that's almost never what we want. In this case,
the runtime implementation doesn't get __type_params__ from
builtins.type either. It's actually defined for the class due to
the use of PEP-695 syntax.
Avasam