Did you check existing issues?
Tree-Sitter CLI Version, if relevant (output of tree-sitter --version)
No response
Describe the bug
I am using the latest version of tree-sitter-python.
I tried to parse this: def f() -> int | str: pass
For the return type I get a type node with a binary operator.
But if we change int by a generic_type, then the type contains an union_type instead of a binary_operator
IMO this is not right. We should be consistent and always have union_type (or remove it and only have binary_operator).
What do you think?
Steps To Reproduce/Bad Parse Tree
Parse those two pieces of code:
'def f() -> str | int: pass'
'def f() -> IO[bytes] | int: pass'
Expected Behavior/Parse Tree
To have an union_type for both and no binary_operator.
Repro
Did you check existing issues?
Tree-Sitter CLI Version, if relevant (output of
tree-sitter --version)No response
Describe the bug
I am using the latest version of tree-sitter-python.
I tried to parse this:
def f() -> int | str: passFor the return type I get a type node with a binary operator.
But if we change int by a generic_type, then the type contains an union_type instead of a binary_operator
IMO this is not right. We should be consistent and always have union_type (or remove it and only have binary_operator).
What do you think?
Steps To Reproduce/Bad Parse Tree
Parse those two pieces of code:
'def f() -> str | int: pass'
'def f() -> IO[bytes] | int: pass'
Expected Behavior/Parse Tree
To have an union_type for both and no binary_operator.
Repro