* betterproto: support `Struct` and `Value`
Signed-off-by: William Woodruff <william@trailofbits.com>
* betterproto: handle struct in to_dict as well
Signed-off-by: William Woodruff <william@trailofbits.com>
* tests: add Struct roundtrip tests
Signed-off-by: William Woodruff <william@trailofbits.com>
* specialize from_dict and to_dict on Struct
...rather than special-casing in the Message ABC.
Signed-off-by: William Woodruff <william@trailofbits.com>
* betterproto: `poe format`
Signed-off-by: William Woodruff <william@trailofbits.com>
* Update src/betterproto/__init__.py
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
* remove future annotations
Signed-off-by: William Woodruff <william@trailofbits.com>
* replace type[...] with typing.T
Signed-off-by: William Woodruff <william@trailofbits.com>
* quote instead
Signed-off-by: William Woodruff <william@trailofbits.com>
---------
Signed-off-by: William Woodruff <william@trailofbits.com>
Co-authored-by: James Hilton-Balfe <gobot1234yt@gmail.com>
Continuing work from #484 by @kevinaud to fix#419
* Implementing pickle methods
* Implement __copy__, __reduce__, and fix __setstate__
* Moved pickling tests into their own file
* Add test for caching
* Add support for streaming delimited messages
This allows developers to easily dump and load multiple messages
from a stream in a way that is compatible with official
protobuf implementations (such as Java's
`MessageLite#writeDelimitedTo(...)`).
* Add Java compatibility tests for streaming
These tests stream data such as messages to output files, have a
Java binary read them and then write them back using the
`protobuf-java` functions, and then read them back in on the Python
side to check that the returned data is as expected. This checks
that the official Java implementation (and so any other matching
implementations) can properly parse outputs from Betterproto, and
vice-versa, ensuring compatibility in these functions between the
two.
* Replace `xxxxableBuffer` with `SupportsXxxx`
This change ensures that deprecation warnings are only raised when
either a deprecated field is explicitly set or a deprecated message is
initialised.
Resolves: #347
Closes#303
* Format field comments also as docstrings
To make it clear that they refer to the item above.
* Fix placement of enum item docstrings
* Add line breaks after class attribute or enum item docstrings
* Update protobuf pregenerated files
* Update grpcio-tools to latest version
* Implement proto3 field presence
* Fix to_dict with None optional fields.
* Add test with optional enum
* Properly support optional enums
* Add tests for 64-bit ints and floats
* Support field presence for int64 types
* Fix oneof serialization with proto3 field presence (#292)
= Description
The serialization of a oneof message that contains a message with fields
with explicit presence was buggy.
For example:
```
message A {
oneof kind {
B b = 1;
C c = 2;
}
}
message B {}
message C {
optional bool z = 1;
}
```
Serializing `A(b=B())` would lead to this payload:
```
0A # tag1, length delimited
00 # length: 0
12 # tag2, length delimited
00 # length: 0
```
Which when deserialized, leads to the message `A(c=C())`.
= Explanation
The issue lies in the post_init method. All fields are introspected, and
if different from PLACEHOLDER, the message is marked as having been
"serialized_on_wire".
Then, when serializing `A(b=B())`, we go through each field of the
oneof:
- field 'b': this is the selected field from the group, so it is
serialized
- field 'c': marked as 'serialized_on_wire', so it is added as well.
= Fix
The issue is that support for explicit presence changed the default
value from PLACEHOLDER to None. This breaks the post_init method in that
case, which is relatively easy to fix: if a field is optional, and set
to None, this is considered as the default value (which it is).
This fix however has a side-effect: the group_current for this field (the
oneof trick for explicit presence) is no longer set. This changes the
behavior when serializing the message in JSON: as the value is the
default one (None), and the group is not set (which would force the
serialization of the field), so None fields are no longer serialized in
JSON. This break one test, and will be fixed in the next commit.
* fix: do not serialize None fields in JSON format
This is linked to the fix from the previous commit: after it, scalar
None fields were not included in the JSON format, but some were still
included.
This is all cleaned up: None fields are not added in JSON by default,
as they indicate the default value of fields with explicit presence.
However, if `include_default_values is set, they are included.
* Fix: use builtin annotation prefix
* Remove comment
Co-authored-by: roblabla <unfiltered@roblab.la>
Co-authored-by: Vincent Thiberville <vthib@pm.me>
John CollinsandGitHub
Erik FrieseandGitHub
Sebastian PietrasandGitHub
VasiliosandGitHub
Joshua LeiversandGitHub
Micael JarniacandGitHub
Joshua LeiversandGitHub
AndrewandGitHub
Alexander KhabarovandGitHub
Nick DeRobertisandGitHub
pi-slhandGitHub
Samuel YvonandGitHub
Wouter HorréandGitHub
sterliakovandGitHub
Antonín ŘíhaandGitHub
MaxandGitHub
Gabriel PajotandGitHub
Eitan MosenkisandGitHub
Michael OsthegeandGitHub
Danil AkhtarovandGitHub
efokschanerandGitHub
