Update type annotations for `run_in_executor` and `set_default_executor` in asyncio event loop interfaces to use more specific executor types from `concurrent.futures`
`zipfile._path` was split into a separate module in Python 3.12.
Originally, we just copied the definition for `CompleteDirs` and `Path`
from `zipfile.pyi` to `zipfile/_path/__init__.pyi` and left the now
defunct version_info branches. This removes the unnecessary branches
from the respective stub files.
* Copy overloads of `open()` to `TarFile.open()`.
* Replace remaining instances of `IO` with `_Fileobj`.
* Replace `open()` with alias to `TarFile.open()` to match implementation.
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...
Joren Hammudoglu