search

googleapis / gapic-generator-python

Generate Python API client libraries from Protocol Buffers.
Apache License 2.0
122 stars 69 forks source link

Contributions open for passing messages as types instead of strings to `Field`? #1036

Open henribru opened 3 years ago

henribru commented 3 years ago

Hi. I'm the author of an (unofficial) type stubs package for google-ads-python. As part of that work I'm also working on type stubs for proto-plus. I'm currently looking into an approach where the types of fields are inferred through a number of overloads on the Field constructor. This approach is working out decently well, but it falls apart when message types are passed as strings. Unfortunately the generated code for the Google Ads library passes all message types defined in the same file as strings. The relevant code is here and here. My question is whether a contribution to replace the described conservative approach would be accepted. My idea is to topologically sort the message types and only fall back to passing strings if they don't form a DAG. I believe this change would allow me to type most messages in the Google Ads library, so I'd be happy to contribute it if possible.

software-dov commented 3 years ago

That seems like an interesting project; sure, if you can make it work and have some tests showing that pathological cases still get handled as strings. I think it's probably necessary to move nested message definition before field definition in the templates in addition to doing the topological sort. Also, keep in mind that some message definitions can be recursive; I think there's some messages in BigQuery like that, since you can arbitrarily nest select/from/where.