-
Notifications
You must be signed in to change notification settings - Fork 229
Enum doesn't get mapped on receive #157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for creating this issue. Yes I think it would be nicer if the enum values were used when deserialising or as the default value. There's an open question of whether values should be altered on assignment, since currently no such magical behaviour exists in betterproto. I suspect it's better not to, though could be convinced otherwise. Feel free to submit a PR with a solution, or just a failing test case. |
The simplest test case (diff from bf9412e) diff --git a/tests/test_features.py b/tests/test_features.py
index f548264..f4940d3 100644
--- a/tests/test_features.py
+++ b/tests/test_features.py
@@ -84,6 +84,16 @@ def test_enum_as_int_json():
foo.bar = 1
assert foo.to_dict() == {"bar": "ONE"}
+def test_enum_mapped_on_init():
+ class TestEnum(betterproto.Enum):
+ ZERO = 0
+ ONE = 1
+
+ @dataclass
+ class Foo(betterproto.Message):
+ bar: TestEnum = betterproto.enum_field(1)
+
+ assert Foo().bar.name == TestEnum.ZERO.name
def test_unknown_fields():
@dataclass I would say having enum mapped at least on init and deserialization would be a good idea, as enum has some additional fields (like |
class TestEnum(betterproto.Enum):
ZERO = 0
ONE = 1
@dataclass
class Foo(betterproto.Message):
bar: TestEnum = betterproto.enum_field(1)
f = Foo()
print(f.from_dict(f.to_dict(include_default_values=True)))
g = Foo(1)
print(g.from_dict(g.to_dict()))
Foo(bar=<TestEnum.ZERO: 0>)
Foo(bar=<TestEnum.ONE: 1>) |
Hi,
Enums seem not to be mapped on init and receive and left as their integer values.
Example proto:
For
TestRequest()
, theCategory
value will be int 0 and notSOMETHING
.When receiving
category = 1
over gRPC, it will be also left as int 1.For deserialization it can be fixed easily by adding yet another branch to
_postprocess_single
. For plain init - I've tried tracing it down, but it seem to go somewhere deep into how dataclasses workThe text was updated successfully, but these errors were encountered: