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
* Move google protobuf from 2 to 2and3
This should generally be ok. I ran the internal consistency
tests and they seemed to pass.
* Convert str to bytes
* repr to use str in google.protobuf.internal.containers
Nipunn Koorapati