Per the suggestion in https://github.com/dropbox/mypy-protobuf/issues/344
This generates more permissive constructors (which protobuf itself actually
accepts).
Philosophically, I think it makes sense for the generated code hosted on
typeshed to be most permissive, while the generated code of individual
projects can make individual decisions (defaulting to less permissive).
I added stubtest testing for generated files within mypy-protobuf.
There are many ways in which the protobuf code is doing *weird*
things and we want the stubs to look a bit different. They're enumerated
in the `stubtest_allowlist.txt` of mypy-protobuf, so squashing them here
so that this one can focus on the non-generated files.
See https://github.com/dropbox/mypy-protobuf/issues/244 for the
inspiration for this. Repeated extensions are allowed by protobuf,
and they generate to extension values with repeated fields.
Notably map fields (ScalarMap and MessageMap) are NOT allowed to be
extension values - producing errors as such - so those are omitted.
testproto/test_extensions3.proto:19:6: Map fields are not allowed to be extensions.
Proto itself supports primitives, not just messages.
See https://github.com/dropbox/mypy-protobuf/issues/244 for an example
motivating this change.
Test Plan: I was able to use MYPYPATH to test an updated version of
mypy-protobuf with this change.
It was there for compatibility to older versions of mypy-protobuf.
With modular typeshed, this sort of straddling code will no longer
be necessary! Thanks @ilevkivskyi
* pyright: disable reportUnknownParameterType
Unknown parameter types are preferred over Any annotations for
incomplete stubs. Especially larger stubs are expected to be
incomplete for some time and it would be a shame to lose the
other pyright warnings for those stubs.
* Also disable reportUnknownVariableType
Fix problems with tkinter
* Disable reportUnknownMemberType
Fix pyright problems
I'm not sure what the best way to do this is. This effectively orphans
types-typing-extensions, but maybe that's not really a problem. (We can
yank the package too)
See https://github.com/python/typeshed/pull/5229#issuecomment-822234125
for some details
Co-authored-by: hauntsaninja <>