[Python][23.5.9] Type annotations in generated code without enabling --python-typing.
akb825 opened this issue · comments
When generating Python code, type annotations always appear on functions that don't have the type prefix. For example, take the following output for the Texture type:
def TextureAddUsage(builder, usage):
builder.PrependUint32Slot(1, usage, 0)
def AddUsage(builder: flatbuffers.Builder, usage: int):
TextureAddUsage(builder, usage)
The legacy function (TextureAddUsage) doesn't contain type annotations, but the new function (AddUsage) does.
See also similar behavior for vector functions with this example for the View type:
def ViewStartFramebuffersVector(builder, numElems):
return builder.StartVector(4, numElems, 4)
def StartFramebuffersVector(builder, numElems: int) -> int:
return ViewStartFramebuffersVector(builder, numElems)
The only options (apart from the input and output files) are -p --no-warnings. I don't pass --python-typing, so I would expect no type annotations to be output. In fact, since it outputs type annotations without the proper imports, it will output errors when attempting to import or run the Python code.
This should have been fixed in git master branch. See #7960.
@yan12125 Would it be possible to have this in a release? It's currently broken in rolling Linux releases or homebrew on Mac that are on the latest stable release tag.
Sorry, I cannot give an answer as I'm just a casual contributor. Looks like recent releases are handled by @dbaileychess.
By the way, I hold on updating flatbuffers package in Arch Linux due to this and some other Python issues.
FWIW, the issue is gone with 23.5.26
Unfortunately I'm still seeing this issue with Start*Vector() functions. e.g.:
def StartDataVector(builder, numElems: int) -> int:
I've submitted #7983 to fix this remaining issue, from what I can tell type annotations are no longer emitted unless requested.
This issue is stale because it has been open 6 months with no activity. Please comment or label not-stale, or this will be closed in 14 days.
not-stale
@dbaileychess I see you have been going through PRs again recently, my fix (#7983) is still waiting for review and is only a few lines of code change.