Joshua Haberman

> To understand correctly, you'd recommend building a static upb as part of the building the python bindings (but not shipping it)? My goal is that our source package, as...

> What I'd love is to have a semi-supported way to build the python bindings against existing libraries There are two main obstacles to this: The first is that the...

Unfortunately I made that comment before considering that we don't have a clear set of APIs to put into `libupb.so`, in order to version it.

I think RBS is a promising direction here: https://blog.appsignal.com/2021/01/27/rbs-the-new-ruby-3-typing-language-in-action.html We could make the main generated code `foo_pb.rb` nothing but a serialized descriptor. Then we could have a separate `foo_pb.rbs` file...

> My expectation is that SerializeToString should return false and UTF8 validation should be treated as error for both decoding and encoding of a message. I think it might be...

FYI protobuf version 22.0 finally removed these internal APIs. It looks like grpc-httpjson-transcoding never migrated off them. So this project will need to continue using protobuf

Sorry for the slow reply. Does PHP provide a guarantee? What happens if you call `setSeconds("123")` in your example?

The `DESCRIPTOR._options` symbol is prefix-underscored and therefore internal to the implementation. To get file options, you should use public APIs like `DESCRIPTOR.GetOptions()`: https://googleapis.dev/python/protobuf/latest/google/protobuf/descriptor.html#google.protobuf.descriptor.FileDescriptor.GetOptions If you have a case where the...

I believe this should be resolved now. Please re-open if it occurs again.

I think the main things blocking this now are just: 1. Deciding on a consistent set of semantics. 2. Implementing those semantics. 3. Waiting for a breaking change release (if...