I believe this covers both #647 and #719.
Moved sqlalchemy stubs from 2 to 2and3;
changed sqlalchemy/util/compat.pyi:37 to be of type typing.Text;
added incomplete stubs for sqlalchemy.orm.utils and slqalchemy.sql.elements.ColumnElement.
Also adds the bare minimum of stubs for
cryptography.hazmat.primitives.asymmetric to define the types
referenced here. (cryptography is a full project in its own right,
with lots of types and internal references.)
This tries to use bytes in places where the module documentation
emphasized that this was opaque bytes and str for arguments and
return values that the module seemd to be treating as regular Python
strings, even though this distinction is not horribly meaningful for
Python 2.
* Add support for request.get's 'params' param
Requests defines the following API:
`get(url, params=None, **kwargs)`
* Improve typing for requests.get(params)
Add support for string form, and tighten restrictions for the dict form
to allow only string keys/vals. Technically, anything is allowed since
the code (I guess) runs `str(key)` and `str(value)`, but it seems better
to keep the stub somewhat strict so it can help pick up potential
errors.
Starting with python/mypy#2521 mypy is performing stricter function signature
checks.
This makes the stubs diverge from the actual implementation but makes the stubs
internally consistent. Since this is an actual typing issue in the base
implementation, we need to defer to the original authors to fix it.
Starting with python/mypy#2521 mypy is performing stricter function signature
checks.
This makes the stubs diverge from the actual implementation but makes the stubs
internally consistent. Since this is an actual typing issue in the base
implementation, we need to defer to the original authors to fix it.
Starting with python/mypy#2521 mypy is performing stricter function signature
checks.
This makes the stubs diverge from the actual implementation but makes the stubs
internally consistent. Since this is an actual typing issue in the base
implementation, we need to defer to the original authors to fix it.
python/mypy#2380 showed a discrepancy between object and FunctionType in stdlib2. The first defined __doc__ to be str, the second Optional[str]. As FunctionType depends on object, this is no longer valid.
As suggested by @gvanrossum in python/mypy#2380, all __doc__ should be considered Optional.
(Final verdict was just to remove most __doc__ attributes since it's inherited from object.)
