Aidan

Yes, that's what I used in my pbjson update, but either way, it's a breaking change if you want to support unknown Fields

Right. I was saying that enabling unknown fields is a breaking change, and in all other languages it is just implicitly supported. I don't think there is a current way...

Random thought. Protobuf naming guide recommends not using underscores as the initial character. Although it's not enforced, suggesting or using a default struct field name with a underscore prefix would...

https://github.com/protocolbuffers/protobuf/issues/23670 This is at least one difference. There are also differences in enum value types that are incompatible across the 2 implementations. So it would be a breaking change.

There is now a somewhat up to date comparison [here](https://github.com/nipunn1313/mypy-protobuf/blob/main/README.md#differences-between-the-protobuf-compiler---pyi_out-and-mypy-protobuf)

Do you have an idea of whether you would update the stub definitions, or change the bindings to support kwarg as well? I'm making some changes in mypy-protobuf, and wouldn't...

Makes sense. I'll hold off on changing mypy-protobuf then.

There is a backported package [backports.strenum](https://pypi.org/project/backports.strenum/) that I've been using for legacy code. I was testing out the latest main, and there is a regression. Using that `StrEnum` package, I...

I didn't actually test it with 3.11 I'm realizing. I'll do that later. Confirmed same behavior on 3.12 and commit `706be0a6e7e09936511198f2ff8982915520d138`

This works if building a custom ISO, but the default ones built for the elemental pipeline still contain it. Which is used by elemental operator Maybe this is an elemental...