* Added object.__sizeof__
* Removed __sizeof__ inherited from object
* Made sqlite3 classes for Python 2 inherit from object
* Removed __sizeof__ inherited from object
Without this change, mypy can't infer proper types for cases like
`d.get(k, [])` where it needs type context to infer the type of
`[]`. We add the value type to the second argument to `get` using
union types, and this provides the context. This doesn't affect
the effective signature of `get`, other than providing the type
context for mypy.
Also removed some related redundant method definitions where we can
just inherit the base class definition. This makes it easier to
keep the method signatures consistent.
Note that this requires a few mypy PRs before mypy will be able to
use this effectively:
* https://github.com/python/mypy/pull/2718
* https://github.com/python/mypy/pull/2715
This type is something core to Python and is useful when typing web applications,
but doesn't actually exist in the stdlib anywhere. I put this in wsgiref, but I am
open to suggestions as for a better place.
(Original PR by @rowillia.)
**test_next.py**:
```python
z = (x*2 for x in range(10))
reveal_type(next(z, None))
```
Before:
```shell
test_next.py:2: error: Revealed type is 'builtins.int*'
```
After:
```shell
test_next.py:2: error: Revealed type is 'Union[builtins.int*, builtins.None]'
```
This chage more closely matches the behavior of `get` at runtime. Users can pass whatever they want in to the default
parameter and it will be returned if the key is absent. Additionally, `get` should return an `Optional` if called with
only one parameter.
```python
z = {'a': 22}
reveal_type(z.get('b'))
reveal_type(z.get('b', 22))
reveal_type(z.get('b', 'hello'))
```
Before:
```shell
test_get_default.py:2: error: Revealed type is 'builtins.int*'
test_get_default.py:3: error: Revealed type is 'builtins.int*'
test_get_default.py:4: error: Revealed type is 'builtins.int*'
test_get_default.py:4: error: Argument 2 to "get" of "dict" has incompatible type "str"; expected "int"
```
After:
```shell
test_get_default.py:2: error: Revealed type is 'Union[builtins.int*, builtins.None]'
test_get_default.py:3: error: Revealed type is 'builtins.int'
test_get_default.py:4: error: Revealed type is 'Union[builtins.int, builtins.str*]'
```
According to the documentation in the typing module, TypeVars cannot
have only a single constraint. Attempting to do so will actually result
in an exception at runtime. (However, this error is currently ignored
by mypy -- see https://github.com/python/mypy/pull/2626 for a related
pending pull request).
This commit changes all instances of TypeVars using a single constraint
(e.g. `T = TypeVar('T', Foo)`) to use bounds instead (e.g.
`T = TypeVar('T', bound=Foo)`.
This seems to be the correct fix for plistlib after reading the module
docs, but it's less obvious this is correct for unittest. The unittest
module originally had `_FT = TypeVar('_FT', Callable[[Any], Any])` -- an
alternative fix would have been to do `_FT = Callable[[Any], Any]`.
Although I'm not entirely sure what it means to have a bound be a
Callable, I decided to make the assumption that the original authors
probably meant to use TypeVars instead of type aliases for a reason
(possibly to handle classes implementing `__call__`?)
* Define __slots__ for object as Iterable[str] / Iterable[Union[str, unicode]]
* A string as __slots__ value is also valid and represents a single item
Correctly detects calls to `register()` with a function of incompatible return
type. Correctly recognizes the `register()`, `dispatch()`, and
`_clear_cache()` methods on a generic function, as well as the `registry`
mapping.
Possible future improvements: it would be amazing if `register()` checked if
the first argument of the registered callable is indeed of valid type. This
would require Callable[] to support varargs. It would also be great if we
could read the arguments of the remaining arguments during `@singledispatch()`
and cross-check them during `register()` with the currently registered
implementation. Again, this would require Callable[] to become much more
advanced.
