Skip to content
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

to_dict on empty nested types #200

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

kilimnik
Copy link

The issue is described here #199.

It was a very simple fix. I don't think a test case is neccesary for this bug. If you think otherwise I can add one.

@kilimnik
Copy link
Author

I analyzed the code a bit more. The problem why so many test fail is that currently the library doesn't know the difference between an uninitialized field and a field which is initialized with an empty object.

@@ -875,6 +874,10 @@ def parse(self: T, data: bytes) -> T:
)

current = getattr(self, field_name)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be moved below that if statement

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The line 879 uses the current attribute, so putting that below doesn't make any sense

@@ -875,6 +874,10 @@ def parse(self: T, data: bytes) -> T:
)

current = getattr(self, field_name)

if self.__raw_get(field_name) == PLACEHOLDER:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use is not ==

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And maybe there should be a return on this

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why should there be a return here? The for loop has to continue

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I meant continue

@@ -972,6 +975,8 @@ def to_dict(
)
):
output[cased_name] = value.to_dict(casing, include_default_values)
elif self.__raw_get(field_name) != PLACEHOLDER:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar thing here, should be is not

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about that but I saw line 540 doing the same comparison

@@ -17,7 +17,7 @@ class Foo(betterproto.Message):
assert betterproto.serialized_on_wire(foo.bar) is False

# Serialized after setting something
foo.bar.baz = 1
foo.bar = Bar(baz=1)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing all this is a regression if this PR breaks this

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know that isn't great. My PR would break lazy initialization. If you want to keep that, I have to think of another implementation. But lazy initialization also isn't in the google implementation, so I thought it wouldn't be important.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well breaking things isn't good. I know how this can be fixed it's been discussed before but it involves every field having a serialized attribute or similar.

@nat-n
Copy link
Collaborator

nat-n commented Jan 24, 2021

Hi @dk99, thanks for working on this.

I analyzed the code a bit more. The problem why so many test fail is that currently the library doesn't know the difference between an uninitialized field and a field which is initialized with an empty object.

I believe this is by design in order to be in line with proto3 semantics, whereby primitive type fields are interpreted as their zero value if unset, and vice versa.

More generally I think the fix for this bug should be isolated to the to_dict structuring logic and shouldn't have any implications for the parsing or internal representation of object. Unless I'm missing something?

I know that isn't great. My PR would break lazy initialization. If you want to keep that, I have to think of another implementation. But lazy initialization also isn't in the google implementation, so I thought it wouldn't be important.

As I mentioned in slack channel, as I recall lazy initialisation is required for recursive message types to work, so I suspect the google implementation actually does support it.

As for testing, ideally we should have a test case for this in line with the pattern documented here: https://github.com/danielgtaylor/python-betterproto/tree/master/tests Let me know if this doesn't turn out to be trivial (the test setup needs some work which has been done in other pending PRs).

@nat-n nat-n mentioned this pull request Jan 25, 2021
@nat-n nat-n added the bug Something isn't working label Apr 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants