Skip to content

Use correct default type for str #8623

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

fliiiix
Copy link
Contributor

@fliiiix fliiiix commented Jun 23, 2025

Otherwise mypy will correctly flag code like this

def __init__(self):
  self.fooBar = None  # type: str

error: Incompatible types in assignment (expression has type "None", variable has type "str")

@github-actions github-actions bot added c++ codegen Involving generating code from schema python labels Jun 23, 2025
@fliiiix fliiiix force-pushed the bugfix/correct-str-default branch from 2622f40 to ad1b601 Compare June 25, 2025 06:15
@akb825
Copy link
Contributor

akb825 commented Jun 26, 2025

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]?

@fliiiix
Copy link
Contributor Author

fliiiix commented Jun 26, 2025

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.

Otherwise mypy will correctly flag code like this

def __init__(self):
  self.fooBar = None  # type: Optional[str]

error: Incompatible types in assignment (expression has type "None", variable has type "str")
@fliiiix fliiiix force-pushed the bugfix/correct-str-default branch from ad1b601 to c6101da Compare June 26, 2025 18:06
@akb825
Copy link
Contributor

akb825 commented Jun 26, 2025

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]]]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c++ codegen Involving generating code from schema python
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants