This adds a few stubs that are used by absl-py, and, without them, cause
type checker errors under Pytype:
* TestCase._formatMessage
* TestCase._testMethodName
* TestCase._getAssertEqualityFunc
* TestProgram.runTests
The __new__ method should suffice, and having both interferes with providing
a __new__ in namedtuples, which we want to do to fix
https://github.com/python/mypy/issues/1279.
* Add ExcInfo and OptExcInfo type aliases
* Implement StartResponse using a protocol
* Mark stub-only types with an underscore
* Remove wrong TODO note
python/mypy#1178 is about variable-length tuples, while exc_info()
always returns a tuple with length 3. Ideally, exc_info() would
return Union[Tuple[Type[_E], _E, TracebackType], Tuple[None, None, None]],
but that is a different issue.
It seems that code using HTTPError previously worked by accident
because we used to accept arbitrary keyword arguments when
instantiating BaseException, or any subclass of BaseException
(see https://github.com/python/typeshed/pull/2348).
This commit adds in the correct constructor (which also lets the
user specify the arguments in keyword-argument form).
Note: I'm not very familiar with the urllib libraries, so I opted
to just add the signature and leave it up to somebody else to
fill in the types.
* Drop support for Python 3.3
* Merge Python 2 and 3 shutil
* Marked some arguments optional
* Changed callback return type from None to Any for more flexibility
In short, this change makes sure calls like `map(None, a, b)` behave as
expected when using `--no-strict-optional` is enabled.
For additional context, see https://github.com/python/mypy/issues/5246
Fixes#1850.
The fix was already applied to Python 2, but the typevar-based solution there
leads to "cannot infer value of type variable" in mypy. I used the following
script to check:
```python
from itertools import product
reveal_type(product([1]))
reveal_type(product([1], ['x'], [False], [3.0], [(1,)], [('x',)], [{1}], [{1: 2}], repeat=5))
```
Basically, the same thing as [my previous pull request][0], except the
fixes are now focusing on functions with overlapping argument counts.
[0]: https://github.com/python/typeshed/pull/2138
This commit reorders any overloads where the first overload was
"shadowing" the second, preventing it from ever being matched by type
checkers that work by selecting the first matching overload alternative.
For example, the first overload alternative below is strictly broader
then the second, preventing it from ever being selected:
class Parent: pass
class Child(Parent): pass
@overload
def foo(x: *int) -> Parent: ...
@overload
def foo(x: int, y: int) -> Child: ...
The correct thing to do is to either delete the second overload or
rearrange them to look like this:
@overload
def foo(x: int, y: int) -> Child: ...
@overload
def foo(x: *int) -> Parent: ...
Rationale: I'm currently [working on a proposal][0] that would amend
PEP 484 to (a) mandate type checkers check overloads in order and
(b) prohibit overloads where an earlier alternative completely shadows
a later one.
[0]: https://github.com/python/typing/issues/253#issuecomment-389262904
This would prohibit overloads that look like the example below, where
the first alternative completely shadows the second.
I figured it would be a good idea to make these changes ahead of time:
if my proposal is accepted, it'd make the transition smoother. If not,
this is hopefully a relatively harmless change.
Note: I think some of these overloads could be simplified (e.g.
`reversed(...)`), but I mostly stuck with rearranging them in case I was
wrong. The only overload I actually changed was `hmac.compare_digest` --
I believe the Python 2 version actually accepts unicode.
