This pull request is a follow-up to https://github.com/python/mypy/issues/7214.
In short, within that mypy issue, we found it would be helpful to
determine between contextmanagers that can "swallow" exceptions vs ones
that can't. This helps prevent some false positive when using flags that
analyze control flow such as `--warn-unreachable`. To do this,
Jelle proposed assuming that only contextmanagers where the `__exit__`
returns `bool` are assumed to swallow exceptions.
This unfortunately required the following typeshed changes:
1. The typing.IO, threading.Lock, and concurrent.futures.Executor
were all modified so `__exit__` returns `Optional[None]` instead
of None -- along with all of their subclasses.
I believe these three types are meant to be subclassed, so I felt
picking the more general type was correct.
2. There were also a few concrete types (e.g. see socketserver,
subprocess, ftplib...) that I modified to return `None` -- I checked
the source code, and these all seem to return None (and don't appear
to be meant to be subclassable).
3. contextlib.suppress was changed to return bool. I also double-checked
the unittest modules and modified a subset of those contextmanagers,
leaving ones like `_AssertRaisesContext` alone.
Per the docs, globals/locals is an optional argument.
Additionally, globals/locals can be any mapping type, not only a dict.
Likewise, fromlist can be any sequence (the docs mention a tuple, not a
list).
The function returns a ModuleType, not Any.
I realized while working on srittau/type-stub-pep#64 that a
few things we do in existing enum definitions in typeshed are
problematic:
- Using "= ..." doesn't allow type checkers to correctly type the
result of Enum.MEMBER.value. In fact, mypy at least infers
.value to be "Ellipsis" if you do this.
- Properties on the enum values themselves, like HTTPStatus.phrase,
should not be specified directly as attributes, because it makes
type checkers think that the properties themselves are enum
members.
I ended up doing a bit more cleanup to the signal module:
- Remove unnecessary ... initializers.
- Remove unnecessary _SIG = Signals alias.
- I don't have Windows to test, but the C code for _signal suggests
that CTRL_C_EVENT and CTRL_BREAK events are not Signals, but just ints:
1dbd084f1f/Modules/signalmodule.c (L1575)
The following code works:
>>> print(sys.version)
2.7.16 (default, Mar 11 2019, 18:59:25)
>>> def f(): pass
>>> print(f.__code__)
<code object f at 0x7f8534ecc8a0, file "<stdin>", line 1>
>>> isinstance(f.__code__, types.CodeType)
True
but it didn't type-check with `mypy --python-version 2.7`.
* error is an alias for OSError in Python 3
* herror and gaierror can be constructed without arguments (tested
in Python 2.7 and 3.7)
* timeout uses the same arguments as herror and gaierror
The implementation of `logging.adapters.QueueHandler` and `logging.adapters.QueueListener` works great with `queue.SimpleQueue` too, so update the stub to reflect this.
The new queue.SimpleQueue class (introduced in 3.7) is faster but is not a Queue subclass as it doesn't implement task handling (`handle_task()` / `join()`) or queue bounds (raising `queue.Full` / `full()`). The logging handler / listener implementations do not make use of those features however.
Related Python bug, asking for an explicit documentation mention: https://bugs.python.org/issue37469
The Pull Request #1121 added the `AddressFamily` type to `socket.pyi`
for Python 3.4+, so constants such as `AF_INET` are correctly
represented as being an enum member rather than an int. The same is
true of the `SocketKind` enums in the `SOCK_*` family.
Various functions in the socket module can accept either an int
or an `AF_*` enum member as arguments, which is allowed by the
int argument type. However the `getaddrinfo` function returns an
`AddressFamily` member rather than an int in the first position
of its list members, so code that access enum specific members
such as the `name` attribute causes a typing error to be found.
This change corrects the return type of `getaddrinfo` but leaves
the family parameters as int, given that `AddressFamily` members
are `IntEnum` and only ever treated as `int`s internally.
