fix(python): correct type dispatch in infer_field for custom classes#3432
fix(python): correct type dispatch in infer_field for custom classes#3432SURYAS1306 wants to merge 5 commits intoapache:mainfrom
Conversation
|
@SURYAS1306 Could you add tests for cases which type inference goes wrong? |
| self.y = "hello" | ||
|
|
||
| # Should not raise TypeError and must be treated as STRUCT | ||
| assert _infer_field("", Empty).type.id == TypeId.STRUCT |
There was a problem hiding this comment.
This may be wrong, only dataclass should be taken as struct. The current struct seiralizer is DataclassSerializer and it only support dataclass too
|
Hi @chaokunyang, Please let me know if you’d like additional edge cases to be covered. |
| @@ -249,11 +249,17 @@ def infer_field(field_name, type_, visitor: TypeVisitor, types_path=None): | |||
| else: | |||
| raise TypeError(f"Collection types should be {list, dict} instead of {type_}") | |||
| else: | |||
| if is_function(origin) or not hasattr(origin, "__annotations__"): | |||
| if is_function(origin): | |||
There was a problem hiding this comment.
So I do not understand, what does this fix exactly?
There was a problem hiding this comment.
Previously, types without __annotations__ (including non-dataclass classes) were being routed through the same branch as functions due to the or not hasattr(origin, "__annotations__") condition.
This caused incorrect type dispatch for custom classes.
By removing the not hasattr(origin, "__annotations__") check, only actual functions are handled in that branch, and class types now follow the intended dispatch path.
Please let me know if I should clarify this further in the PR description.
2 participants
Why?
The current type dispatch logic in
infer_fieldincorrectly treats certain user-defined classes as built-in types due to insufficient origin/type checks.This leads to incorrect field inference and causes Python serialization tests to fail.
What does this PR do?
This PR refines the type dispatch logic in
infer_fieldto properly distinguish between:list,dict,set)User-defined classes are now correctly routed through
visit_customized, while primitives and supported types continue to usevisit_other.All existing Python tests pass after this fix.
Related issues
None.
Does this PR introduce any user-facing change?
No.
Benchmark
Not applicable - this change does not impact performance.