A few comments between imports were removed or moved to the top of the
import block, due to behavioral differences between black and isort. See
psf/black#251 for details.
In two instances @overloads at the top of the file needed to be moved
due to psf/black#1490.
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.
* contextlib.pyi ExitStack.callback take Callable
The documentation for ExitStack does not specify the return type of the callable's passed to callback.
Saying that they always return None breaks a very common use case for ExitStack, which is to "schedule" changes to a collection
while iterating it.
```
with ExitStack() as stack:
for key, value in adict.items():
if ...:
stack.callback(adict.pop, key)
```
I also added AsyncExitStack, using Awaitable.
* Moving to Explicit Any in Generics
* add typing.ContextManager for 3.6+ only
This fixes the easier part of #655.
Would it make sense to add a generic typing.ContextManager that exists in any Python version?
* update comment
* fix argument types for ContextManager.__exit__
* add AsyncContextManager
* add @asynccontextmanager
* typing.ContextManager now always exists
* back out async-related changes
Will submit those in a separate PR later
* fix import order
* AbstractContextManager only exists in 3.6+
* AbstractContextManager -> ContextManager
mypy could not recognize the case when we use contextmanager as a
decorator, which has been supported since Python 3.2.
In the following code snippet,
from contextlib import contextmanager
@contextmanager
def foo(arg1):
try:
print(arg1)
print('1')
yield
finally:
print('2')
@foo('0')
def foo2():
print('3')
foo2()
we get mypy error as follows,
error: ContextManager[Any] not callable
The suggested changes can fix this error and properly reflect the
updated contextmanager usage pattern.
To be on the conservative side I'm making it an Iterable of values;
this should be good enough for common usages.
The types of the values actually correspond to the types of the
argument ContextManagers, but a proper signature would require
variadic type variables (https://github.com/python/typing/issues/193),
which isn't worth waiting for. :-)
