I'm not quite sure this change is correct, since there's a distinct difference between the field being unset and being explicitly set to an empty string. For example, when reading from C++ a string that was set to None would read back to nullptr, as opposed a valid string with length 0. These could have different semantic meanings depending on the intentions for the field.

Perhaps instead of changing the default value, the type should be changed to Optional[str]?

I'm not quite sure this change is correct,
I thought about this and came to the conclusion that empty string might be correcter.
Since the field is not optional. 🤷

BUT im not 100% sure, it did not have a negative impact on my code base.
Im more than happy to change it to Optional[str] which might or might not be more correct.
For my personal purposes both should work fine.

I thought about this and came to the conclusion that empty string might be correcter.
Since the field is not optional.

At least for the flatbuffer schema, strings are optional unless explicitly marked as (required). For the C++ generated code at least, a required string still creates the same code: getting the string returns a pointer rather than a reference, you're just guaranteed that a valid flatbuffer will never be set to nullptr. Also, in the case of string arrays, AFAIK the (required) isn't transitive, i.e. the required array will be guaranteed to be present to be valid, but technically the string members could be null.

FWIW I expect that arrays (represented in Python as lists) would run into the same issues. For example, with monster_test_generated.py I expect self.vectorOfLongs = None # type: List[int] should be self.vectorOfLongs = None # type: Optional[List[int]], while self.testarrayoftables = None # type: List[MonsterT] should be self.testarrayoftables = None # type: Optional[List[Optional[MonsterT]]]

I updated the MR and made Lists also optional, anything else needed here before it can be merged? @akb825 @dbaileychess

Looks good on my end. For an official approval, you may have more luck with @aardappel assuming that @dbaileychess is still on a hiatus.

Yes @akb825 is correct, we should distinguish between no string and empty string. Some language APIs conflate the two for simplicity, but FlatBuffers represents them differently.