Summary
A generated ordinary class can shadow a same-named module-level TypeVar binding, leaving generic references ambiguous or incorrect in the Python Pydantic v2 SDK output.
Required change
Update the Python Pydantic v2 generator's leaf-global name allocation so generated class/module bindings and allocated module TypeVar names cannot collide. Ensure declarations and all type references use the final, collision-free spelling consistently in both .py and .pyi output.
Affected area
baml_language/sdks/python/rust/sdkgen_python_pydantic2/src/leaf.rs
- Related TypeVar allocation and type translation paths
Acceptance criteria
- A schema containing an ordinary identifier class and a module-level
TypeVar with the same emitted name produces distinct legal Python bindings.
- References resolve to the intended class or
TypeVar in generated runtime and stub output.
- Regression coverage verifies the generated files are valid and preserves non-colliding output behavior.
Context
Disclosed as an adjacent follow-up during the reserved-word handling work in #4070.
Summary
A generated ordinary class can shadow a same-named module-level
TypeVarbinding, leaving generic references ambiguous or incorrect in the Python Pydantic v2 SDK output.Required change
Update the Python Pydantic v2 generator's leaf-global name allocation so generated class/module bindings and allocated module
TypeVarnames cannot collide. Ensure declarations and all type references use the final, collision-free spelling consistently in both.pyand.pyioutput.Affected area
baml_language/sdks/python/rust/sdkgen_python_pydantic2/src/leaf.rsAcceptance criteria
TypeVarwith the same emitted name produces distinct legal Python bindings.TypeVarin generated runtime and stub output.Context
Disclosed as an adjacent follow-up during the reserved-word handling work in #4070.