[PR] Surface schema names in type display + polars LazyFrame support [hamilton]

["Dev-iL (via GitHub)" <gi...@apache.org>]

Dev-iL opened a new pull request, #1599:
URL: https://github.com/apache/hamilton/pull/1599

   ## Summary
   
   Two related fixes to Hamilton's pandera integration:
   
   1. **`get_type_as_string` surfaces generic type arguments** — parameterised types like `pandera.typing.polars.LazyFrame[OHLCVSchema]` previously collapsed to `"LazyFrame"` everywhere (DAG visualiser, node tables, MCP tool descriptions, `Node.__repr__`). The fix makes any generic whose type arguments carry `__name__` attributes display as `"Base[Arg]"`, so `LazyFrame[OHLCVSchema]` now renders correctly.
   
   2. **`h_pandera.check_output()` accepts polars annotations** — the decorator previously raised `InvalidDecoratorException` for functions annotated with `pandera.typing.polars.LazyFrame[MySchema]` or `pandera.typing.polars.DataFrame[MySchema]` because the schema-extraction logic only matched the pandas `pandera.typing.DataFrame` path. Both polars container types are now recognised.
   
   ## Changes
   
   | File | What changed |
   |------|-------------|
   | `hamilton/htypes.py` | `get_type_as_string`: when a type has `__name__` and non-empty `get_args()` whose args all have `__name__`, returns `"Base[Arg1, Arg2]"` instead of just `"Base"`. Pandera-agnostic — no new import. |
   | `hamilton/plugins/h_pandera.py` | Added `try/except ImportError` guard for `pandera.typing.polars` imports; extended `get_validators` to recognise `pa_typing_polars.DataFrame` and `pa_typing_polars.LazyFrame` origins in addition to the existing pandas path. |
   | `hamilton/data_quality/pandera_validators.py` | Added `"polars_lazyframe"` to `pandera_supported_extensions` so `PanderaDataFrameValidator.applies_to` recognises `polars.LazyFrame`-derived types. |
   | `tests/integrations/pandera/test_h_pandera_polars.py` | New file (6 tests, gated on `pytest.importorskip("polars")`) covering: `get_type_as_string` output for parameterised and bare `LazyFrame`, validator construction for both polars container types, and end-to-end `dr.execute()` pass/fail for a schema-decorated LazyFrame function. |
   | `CHANGELOG.md` | Created at repo root (no prior file existed); documents both fixes under `[Unreleased]`. |
   
   ## Design notes
   
   - **No pandera import in `htypes.py`** — the `get_type_as_string` change is fully generic; pandera schemas benefit because their schema classes happen to have `__name__`. Other generics (`list[int]`, `dict[str, int]`, `Union[str, int]`) also now surface their args, which is strictly more informative.
   - **Polars is still optional** — the new import block in `h_pandera.py` is guarded with `try/except ImportError`; the `_POLARS_TYPING_AVAILABLE` flag prevents any code path from executing when polars is absent.
   - **Validation backend** — polars LazyFrame validation reuses `PanderaDataFrameValidator.validate`, which calls `schema.validate(data, lazy=True, inplace=True)`. Pandera's polars backend ignores `inplace=True` (emits a `UserWarning`); this is correct behaviour for immutable `LazyFrame`s.
   - **`polars_lazyframe` registration** — tests import `hamilton.plugins.polars_lazyframe_extensions` explicitly to register the type in Hamilton's registry. In real usage this registration happens automatically when users import `h_polars_lazyframe`.
   
   ## Test plan
   
   - [x] `pytest tests/test_type_utils.py -q` — all 158 tests pass (4 pre-existing failures on `test_validate_types_happy[Annotated*]` are unrelated to this PR)
   - [x] `pytest tests/integrations/pandera/test_h_pandera_polars.py -v` — all 6 new tests pass
   - [ ] Manually verify `get_type_as_string(pa_typing.polars.LazyFrame[SomeSchema])` returns `"LazyFrame[SomeSchema]"`
   - [ ] Manually verify `get_type_as_string(polars.LazyFrame)` (bare, no arg) still returns `"LazyFrame"`
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@hamilton.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Surface schema names in type display + polars LazyFrame support [hamilton]

["Dev-iL (via GitHub)" <gi...@apache.org>]

Dev-iL commented on PR #1599:
URL: https://github.com/apache/hamilton/pull/1599#issuecomment-4531686929

   > One question: does `pandera_supported_extensions` adding `"polars_lazyframe"` need a corresponding registration somewhere, or is this set just used for documentation/discovery? Want to make sure there's no missing wiring.
   
   No missing wiring. `pandera_supported_extensions` is purely a filter inside `applies_to` — it gates the registry lookup at line 41: `if extension_name in registry.DF_TYPE_AND_COLUMN_TYPES`. The actual registration lives in `polars_lazyframe_extensions.py` (called at module load time when that module is imported), which is entirely separate from this frozenset.
   
   The pattern is: `pandera_supported_extensions` says "which registered extensions does pandera know how to validate?" — the entry only has effect if the extension is already in `registry.DF_TYPE_AND_COLUMN_TYPES`. If polars isn't installed (and therefore `polars_lazyframe_extensions` was never imported), `"polars_lazyframe"` won't be in the registry and the `if` on line 41 skips it silently. No separate registration needed; this change is self-contained.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@hamilton.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [PR] Surface schema names in type display + polars LazyFrame support [hamilton]

["skrawcz (via GitHub)" <gi...@apache.org>]

skrawcz merged PR #1599:
URL: https://github.com/apache/hamilton/pull/1599


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@hamilton.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org