On Tue, Oct 18, 2016 at 2:06 PM, Mike Bruce <[email protected]> wrote:
> On Tue, Oct 18, 2016 at 3:51 PM Nathaniel Manista <[email protected]> > wrote: > >> On Tue, Oct 18, 2016 at 11:07 AM, <[email protected]> wrote: >> >> When working with gRPC in Python, >> >> >> With what version of gRPC Python are you working, and on what platform? >> Also with what version of protocol buffers are you working? >> > > gRPC 1.0.0, on Linux and Mac. Protobuf 3.1.0 / proto3. > Well that checks out. either implementing a service or client code, it would be great if the >> types of the messages being returned or passed in were checked. That is, if >> my service is defined to return a type Foo, but I construct and return a >> type Bar object, the code should throw an error. >> >> This github issue implies that this is the intended behavior: >> https://github.com/grpc/grpc/issues/3410 >> >> But in fact, I appear to be able to return any Message object without >> throwing any errors. >> >> >> Any message object, or only mutually serializable message objects? >> > > I've poked around with a lot of different combinations, and haven't gotten > anything to fail, as long as it's a Message of some kind. The field types > don't have to line up. I'm testing this doing doing the <message > class>.SerializeToString(<message object>) that you reference in that > github issue. > > >> Is this a bug? >> >> >> No, but if there's an opportunity here to be more helpful to applications >> that contain defects, we're open to it. >> > > Silently accepting bad data doesn't feel great. One of the things about > gRPC that was appealing to us was in having defined types to pass around. > Agreed. Are there different approaches to achieving a schema-like effect, without > writing a bunch of custom code? > > Are there differing opinions on how this should work? >> >> >> There's almost certainly someone out there who believes that since >> message serialization is in the RPC path that it shouldn't incur the >> penalty of explicit type-checking, but that's not my opinion at this time. >> What I am reluctant to do is include explicit type-checking in generated >> code, which is where I would think that it would have to go if the message >> class' serialization method itself doesn't do the type-checking. >> > > What's the source of your reluctance? > An engineering mindset that says that generated code should be as simple as possible, plus this sort of feeling like a feature that belongs on the protobuf side rather than the gRPC side. I wouldn't mind putting some work into this if there was a path forward. > Let's start with a bug report to the protobuf folks <https://github.com/google/protobuf/issues> and see where that takes us? -N -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAEOYnARpS9Qp99S04N3EX2ZzD_Qmwu10Zn2OUppqjEtqKfHwNg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
