Selecting an Optional type during generation

[yamatiro]

Summary

Perhaps it would be a better solution to add an argument for the compiler to choose whether to do so or not, because I have now switched from the first version of betterproto, and there the optional in the generated files is indicated only if the optional is specified in the proto files, and this breaks the transition

What is the feature request for?

The core library

The Problem

The Ideal Solution

The Current Solution

[AdrienVannson]

The problem is that it is not that easy: simply removing the optional type annotation in the compiler would not work.

If two messages A an B are defined, it is entirely possible that A has a (non-optional) field of type B, and B has a non-optional field of type A. Thus, the default value of these fields can't simply be an empty message.

The previous version of betterproto used to rely on a complex mechanism to approach this: the message fields were assigned a placeholder value. When the user was trying to access a field, the placeholder was dynamically replaced by an empty message (by redefining the __getattribute__ method of messages). To know is a message field was there because it was the default value or because it was actually part of the message, an artificial _serialized_on_wire field was added to each message.

This was the cause of many problems, some of them being impossible to solve with this design. Plus, the behavior was really unintuitive (simply reading a field could change a message).

You can see the PR that I did on the original repo for more details (it was not merged on this repo, only on the new one) : danielgtaylor/python-betterproto#641

I'm not sure if there is a simple workaround to mimic the behavior of the previous version without all the problems that came with it (maybe something like adding back a __getattribute__ function to messages to replace None by an empty message when the field is accessed could partially work as a workaround, I will have a look).

[yamatiro]

@AdrienVannson Thanks for the explanation. Yes, now I understand the reason, your decision seems more correct and intuitive.