You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When converting existing code to use this module over standard protobuf, one issue raised was the lack of ParseFromString. This has already been mentioned at #323, with a PR in the works at #336. However, this is blocked because it does not perform the same calls as the standard, namely, Clear. In my use of this module, i have worked around this issue by simply creating a new instance (which is always the default) instead of using an existing one, at which point just calling parse works fine.
Ideally, we'd need a clear function (preferably lowercase to match python syntax, but might want TitleCase for compatibility) on the abstract Message class and an implementation that resets all fields to their default values. We'd need to confirm that our implementation matches standard protobuf when it comes to user-defined default values.
to be clear, this isn't a bug, and it doesn't prevent the use of this module.
I'd look into addressing this myself but the logic used to set default values eludes me, at least at first glance.
The text was updated successfully, but these errors were encountered:
When converting existing code to use this module over standard protobuf, one issue raised was the lack of
ParseFromString
. This has already been mentioned at #323, with a PR in the works at #336. However, this is blocked because it does not perform the same calls as the standard, namely,Clear
. In my use of this module, i have worked around this issue by simply creating a new instance (which is always the default) instead of using an existing one, at which point just callingparse
works fine.Ideally, we'd need a
clear
function (preferably lowercase to match python syntax, but might want TitleCase for compatibility) on the abstract Message class and an implementation that resets all fields to their default values. We'd need to confirm that our implementation matches standard protobuf when it comes to user-defined default values.to be clear, this isn't a bug, and it doesn't prevent the use of this module.
I'd look into addressing this myself but the logic used to set default values eludes me, at least at first glance.
The text was updated successfully, but these errors were encountered: