Checking a Pandas pipeline before moving it to Polars

I have seen migration discussions start with a speed comparison. The harder question for an existing pipeline is often what the code already assumes about Pandas. An implicit index, row iteration, or a Python callback can shape the whole design. I built polars-ready to expose those calls before anyone starts replacing imports.

The CLI accepts a Python file, notebook, or directory. It parses source with the standard library AST and never imports the code it scans. The report names each recognized operation, its source line, a rough category, and a suggested Polars idiom. A directory scan produces a small per-file bar. JSON output makes the same findings available to a migration checklist or CI job.

Here is the install and audit command:

uvx --from git+https://github.com/Arthur031221/polars-ready polars-ready path/to/pipeline.py

Consider a pipeline that reads a CSV, drops missing values, groups sales by region, and writes a summary. Those calls are visible in the output. If the same file uses set_index("date").resample("M"), the report marks index and resampling use for closer review. Polars keeps keys as columns and uses dynamic grouping for time windows. The exact rewrite depends on whether the data is sorted, how windows close, and which rows belong at a boundary. A mechanical substitution would be risky.

The percentage at the top is intentionally modest. It counts recognized calls classified as direct. It does not predict that the full program will work after migration, that its output will match, or that Polars will run faster. The tool is a source inventory, not a converter.

The scanner currently follows common Pandas import aliases and local variables assigned from recognized constructors or calls. It can miss a frame passed through another function or stored in a container. It may also report an unrelated method if a tracked variable name is reused. Notebook cells beginning with a shell or IPython magic are skipped, while other parse errors appear in the report. Those limits are in the README because a silent clean report could give false confidence.

I included a reproducible sales pipeline fixture and tests for alias handling, chained calls, notebook locations, and unrelated method names. The project is MIT licensed. I would like examples where a rule gives the wrong level of concern, particularly for resampling, categorical data, and timezones. The repository is https://github.com/Arthur031221/polars-ready.