There is at least one well-known proto file (plugin.proto) with comments
that include variable-like strings that are not actual variables. This
leads to DFATAL log statements that clutter the output and don't provide
any benefit.
Now the grpc_2_0 flag is no longer required for the only-generate-code-
elements-in-_pb2_grpc.py-files behavior and the grpc_1_0 flag is
required for the add-generated-gRPC-using-code-elements-to-_pb2.py-
files behavior.
We'll soon be flipping the default behavior of gRPC Python Protoc
Plug-In to the later-than-gRPC-1.0 "code elements only in a
separate _pb2_grpc.py file and no Beta-API-using generated code
elements" behavior; this flag will be the supported (supported for a
while, though not exactly sure how long) means of using the older
"also put gRPC-using code elements in the generated _pb2.py file"
behavior that has been in place since gRPC 1.0.
For Flatbuffers compatibility.
From what I can tell, File::additional_headers is not used by gRPC
itself or its default protobuf implementation; it was added for
Flatbuffers support (it just returns "" for protobuf).
In the Flatbuffer case, the generated header contains references to
Flatbuffer gRPC glue code which is in a header in additional_headers.
Prior to this patch, this meant that the generated .h file could not
be included unless this glue file was included first.
Because the protobuf implementation of additional_headers returns
an empty string, I think this change should be safe to do and not
have unintentional consequences.
This changes the import style for proto dependencies from a) to b).
a) "import a.b.c as x"
b) "from a.b import c as x"
Using statement a) causes problems when using __init__ files. If module
"a.b" has an __init__.py file which is importing the python generated
grpc code "a.b.d", then we cannot import a module named "a.b.c" because
the module "a.b" does not exist yet. In this case python will throw:
AttributeError: 'module' object has no attribute 'b'
This PR adapts the code to use the same logic as in:
/google/protobuf/compiler/python/python_generator.cc
Since
#...
class Service:
class NextService:
#...
without a body or `pass` under `Service` is invalid
Python, we ensure a `pass` statement is always
emitted to make the generated code valid.