support for proto3 `optional` (explicit field presence) about python-betterproto

[Gobot1234]

v.2.0.0b4 has just been released and includes support for this.

[kalzoo]

+1 - as a quick(er) fix, even just internally treating the optional field as a oneof with only one option would allow betterproto to be used with protobuf definitions that can currently be handled by other language generators like protoc-gen-go and prost (Rust). On-the-wire that should be compatible, IIUC, and then it would just be a matter of improving ergonomics in Python as time allows.

As it stands, if we select betterproto as our Python generator, we have to remove optional from all of its source proto definitions, even if all other generators can handle it.

[nat-n]

Explicitly representing field optionality makes sense. Actually enforcing it at runtime with python dataclasses would be a bit tricky.

[davidmankin]

I just had a PR in my project reverted because it used optional int32 and a consumer of the proto files uses betterproto.

I wasn't even aware of betterproto, but it looks better in almost every way — except that it doesn't support the new(ish) optional keyword for primitives. Please consider adding this support. (I don't need it to enforce that I only put "None" on optional fields; I just need it to be interoperable with the rest of the protobuf ecosystem. Essentially, what @kalzoo said.)