Akuli

I don't have a strong opinion on this, but I agree that this can be useful. In one project, I had many collections of tasks that I wanted to cancel...

> an argument without a default after an argument with a default value It would be tempting to write this: ```python3 @overload def parse_args(self, args: Iterable[str] | None = ...,...

`CONTRIBUTING.md` already has sections about how to write stubs, such as "Stub versioning" and "Incomplete stubs". I think we could add a new section "Optional arguments before required arguments" or...

It also seems like most of the arguments are keyword-only, even though they aren't marked as keyword-only in the stub: ``` >>> ujson.dump({'a': object()}, sys.stdout, True, 1, True, True, True,...

Related: #7015, #6597

If I understand correctly, the next steps are: - Add a check to `tests/check_consistent.py` that fails if `stubs/foo` depends on anything else than: - A `types-bar` package where `bar` is...

I'm mostly confused about "changes to mypy_test and the others" part. - Why exactly is https://github.com/python/typeshed/issues/5952#issuecomment-1046192164 relevant now? It says "I personally wouldn't hate getting started on [this issue] with...

I personally don't see how duplicating the dependencies into a separate allowlist in the same repository improves security.

> add e.g. nmupy as a dependency (whether intentionally or not) We could fail typeshed's CI and/or stub-uploader if `types-foo` depends on something other than the dependencies of `foo` on...

I would prefer: ``` 1. Manually review the generated stubs in {stub_dir} 2. Run tests locally if you want (see CONTRIBUTING.md) 3. Commit the changes on a new branch and...