The change introduced in 395ab5abd1
broke the signature of `requests.post`, among others, since
`MutableSequence` is invariant, and plain `Dict[str, str]` values
were no longer valid for the `data` argument.
This changes the signature to have `Any` components as a
compromise. Adding more items to the union seems a bit too much, since
the error messages for invalid argument types are already pretty hard to
read.
Another option might be to use `Mapping` instead of `MutableMapping`
due to covariance, but I assume there's a reason why `MutableMapping`
is used here.
The previous definitions in `mock` caused many false positives in
internal Dropbox repositories.
One source of problems was `List[Mock]` not being compatible with
`List[SomeClass]`, since `list` is invariant.
Make the Python 2 and 3 concurrent.futures stubs identical so fixes get
applied to both.
For example, #1305 and #2233 fixed the same problem at different times,
as did #1078 and #1911.
By making the stubs identical, we apply the fix from #1711 to Python 2.
Fixes#2234.
Use parameterized types in Future.add_done_callback(), wait(), and
as_completed().
Mark the traceback argument to Future.set_exception_info() as optional.
This additionally allows strings, bytearrays and string iterables to be
passed as the `response` argument of `BaseResponse` (and thus also
`Response`).
Strings and bytearrays are explicitly handled in `__init__` [1].
Strings are also featured on the Werkzeug front-page snippet (`'Hello
World!'`) [2].
[1]: d129d17066/werkzeug/wrappers.py (L861)
[2]: http://werkzeug.pocoo.org/
The Python 2 version was slightly outdated compared to the Python 3
version.
The Python 2 version of Headers.__delitem__() had an optional argument
_index_operation that also exists in the implementation. But considering
this is internal use only, it was missing from the Python 3 version, and
it created problems with derived classes, I decided not to add it to
the merged stub. See also pallets/werkzeug#1051.
* Move google protobuf from 2 to 2and3
This should generally be ok. I ran the internal consistency
tests and they seemed to pass.
* Convert str to bytes
* repr to use str in google.protobuf.internal.containers
The dict stub was referring to an instance, not the type, leading to
__call__ being considered when using as a decorator, rather than
__init__.
mock is a backport of the stdlib module and should be defined the same.
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.
To support "from six.moves.cPickle import loads", we must add a stub for
six.moves.cPickle as if it were a real submodule, even though it isn't
implemented as such. This fixespython/mypy#1550.
We don't apply this approach to six.moves.builtins on Python 2, because
it seems to confuse mypy.
We also add stubs for aliases in six.moves whose underlying modules have
been added to typeshed.
For Python 2:
- six.moves.SimpleHTTPServer (alias for SimpleHTTPServer)
For Python 3:
- six.moves.tkinter_dialog (alias for tkinter.dialog)
- six.moves.tkinter_filedialog (alias for tkinter.filedialog)
- six.moves.tkinter_commondialog (alias for tkinter.commondialog)
- six.moves.tkinter_tkfiledialog (alias for tkinter.filedialog)
Currently the Python 2 stub for `IntEnum` just inherits from `Enum` without changing anything, meaning that its `value` has type `Any`. This changes it such that, if you know you have an `IntEnum` you get the more specific `int` type for the `value`. Note that this has already been done for Python 3 `IntEnum` (both in `third_party/3/enum.pyi` and `stdlib/3.4/enum.pyi`).
This fixes an error in Travis that seems to have been caused by python/mypy#4319.
The fix was taken from the stdlib/3.4/enum.pyi stub. Mypy no longer assumes
that classes whose metaclass is EnumMeta are subclasses of Enum, so we can't
bound the typevar on Enum.