I did a a cursory investigation using GitHub search and also looked at
a big internal codebase, and a significant fraction of callsites used
a dict type instead of a TypedDict or a dict literal.
It seems that it's a common use case to store the config within an
attribute. For example, something like this:
```
CONFIG = {
...
}
...
logging.config.dictConfig(CONFIG)
```
Another use case that was not properly supported is reading the
config from a file, and the config is given `dict[str, Any]` as
the type.
Mypy can still do some type checking of the argument if called
with a dict literal, so I feel this is a reasonable compromise
between type checking strictness and usability.
This reverts commit 8bda66a737.
The change causes issues with ParamSpec implementations in type
checkers, at least pyright and my work-in-progress support for
ParamSpec in mypy. It's not yet clear how to fix the issues, so I
think that it's best to revert this, at least temporarily until we've
found a good solution. See #6347 for context.
These silence errors about missing type annotations for calls
like these:
```
x = getattr(o, 'a', [])
y = getattr(o, 'b', {})
```
This is basically a generalization of #5518 and other overloads we already
have.
This works around python/mypy#11572. I encountered the issue in several
places when testing recent typeshed against an internal repo.
Docstring description of the argument includes this text:
"Either a string representing URL of the remote server or
a custom remote_connection.RemoteConnection object."
These were generated using stubgen, with manual fixes. I tried to remove
exported names that are clearly not part of the public interface, but in many
cases this wasn't obvious so I left the exports, just in case.
I had to do major changes to exported names in `selenium.webdriver` to
make it work as expected (this was originally implemented by @ilevkivskyi
in our internal stubs).
Selenium has been working on adding inline type annotations, but it's not clear
when these will be released. The release will be 4.x, and having stubs for 3.x
could still be valuable for users on older versions.
I generated these using stubgen and made various manual tweaks to fix issues
reported by stubtest.
Some of the submodules with underscore prefixes are used by open source code,
so I'm including them.
Various definitions are platform-specific. I added some sys.platform checks, but
it's hard to get these right. We may need to iterate on them later.
This tool is a simple wrapper around stubgen and other tools that simplifies the
creation of "baseline" stubs with minimal annotation coverage. These stubs allow
basic type checking (e.g. number of arguments, whether X is valid as a base class),
and once we have baseline stubs, it's easy to contribute incremental changes that
add type annotations.
Here's a summary of what the tool does:
1. Check that the package is installed
2. Run stubgen
3. Copy generated stubs to the correct directory under `stubs/`
4. Run black
5. Run isort
6. Generate basic metadata with correct package version
7. Update pyright exclusions (needed since there are missing types)
8. Print suggestions about next steps needed to contribute stubs to typeshed
For example, to generate stubs for `iso8601`, you can run it like this:
```
python scripts/create_baseline_stubs.py iso8601
```
Sometimes the project name is different from the runtime package name. In
this case run the tool with `--package <runtime-package>`.
These caused false positives, for example in code like this:
```
with freeze_time(None) as ft: # False positive here
ft.tick(3) # False positive here
```
Tornado ships with inline annotations, but it no longer is Python 2
compatible. I think that it makes sense to keep the legacy stubs for
Python 2 compatibility, at least for a while longer.
This restores stubs removed in #4321, but moves them to
`third_party/2`.
Nothing prevents a decorator defined using `@decorator` from
changing the signature of the decorated function. For example,
this example changes the return type to `str`:
```
from decorator import decorator
@decorator
def stringify(f, *args, **kwargs) -> str:
return str(f(*args, **kwargs))
```
The old signature caused false positives in internal Dropbox code.
I couldn't come up with a signature that would produce better types
with mypy while not generating false positives.
This gets imported from `_ast`, so the definition was
redundant. This causes problems with the new mypy semantic
analyzer, as it will flag the redefinition as an error.
This class is not defined at runtime but it's used by
mypy internally to support TypedDict methods.
Use NoReturn in argument types for better type safety
when the related mypy plugin hook is not active.
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.
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
Jukka Lehtosalo