Summary
Compile-time control determines whether fields of a message type are assigned the default value of an empty message instead of None.
What is the feature request for?
The core library
The Problem
The document mentions
When a field is a message, its presence is always tracked explicitly even if it is not marked as optional. Marking a message field as optional has no effect: the default value of such a field is always None, not an empty message.
Is it possible to control this behavior at compile time?
Compile-time control determines whether fields of a message type are assigned the default value of an empty message instead of None.
If this behavior can be controlled when compiling into a .py file, then it's unnecessary to manually initialize each message field when using it.
This definition file serves as an example.
syntax = "proto3";
message Req {
message DataReq {
int64 field_one = 4;
}
DataReq data = 1;
}
You can do this with the fields in the data.
req = Req()
req.data.field_one = 7
Instead
req = Req()
req.data = DataReq()
req.data.field_one = 7
The Ideal Solution
This behavior can be controlled using parameters at compile time.
The Current Solution
No response
Summary
Compile-time control determines whether fields of a message type are assigned the default value of an empty message instead of None.
What is the feature request for?
The core library
The Problem
The document mentions
Is it possible to control this behavior at compile time?
Compile-time control determines whether fields of a message type are assigned the default value of an empty message instead of None.
If this behavior can be controlled when compiling into a .py file, then it's unnecessary to manually initialize each message field when using it.
This definition file serves as an example.
You can do this with the fields in the data.
Instead
The Ideal Solution
This behavior can be controlled using parameters at compile time.
The Current Solution
No response