Definitely one of the advantages of improved tooling visibility, tooling's importance here is obstensibly one of the reasons for the recent acquisition of Astral.

Migrating Pandas to canonical Polars can require some rethinking, since Polars couldn't make a cleaner API model without making things different. From Polars to Typol can really depend: if you have relatively fixed `pl.Schema`s which you join, filter, aggregate, transform between etc., then it should be pretty trivial; the interface is specifically designed to deviate from Polars only where necessary or there is particularly strong case ergonomically. If you really need to add and drop columns all the time, then it might require some more effort. Worst case, you can always have the intermediates in some of your functions still be in Polars, but expose the right shapes with Typol. It's trivial to switch back and forward by doing `typol_df.dataframe` and `tp.DataFrame(MyShape, polars_df)`. This way you're enforcing shape types between sections of your code, and can push that typing inside your functions later.

Naming can end up as a bit of bikeshedding, but if you're interested, right now it needs Ty (until other checkers support intersections), and it's based on Polars, so Ty+Pol seemed the most obvious to users and Googleable.