Why I Switched From Pandas to Polars | TDE Workshop

[@Michael-yu9ix]

The API consistency and the fact that you can actually chain entire complex wrangling tasks are reason enough for me to switch. The learning curve is pretty flat for experienced pandas users. The time you invest in learning polars, you make up for by being more efficient later on. I can't imagine polars not taking over pandas eventually.

[@ИльяОжмегов]

Great Job Ben! 👍

[@feifa13]

Thanks Ilia!

[@spikeydude114]

Although I see the benefits of Polars. I haven't had enough obstacle with Pandas for my workflows. I don't deal datasets that exceed memory and I think currently I can extend my memory limit using Dask ... but looking forward to the development of Polars and will likely adopt once it has more support!

[@virushk]

Same situation here. I find Pandas and Dask to be sufficient tools for my workflows

[@JOHNSMITH-ve3rq]

Chatgpt knows pandas much better. For exploratory work probably not an issue. But if shopping something to prod and want to keep it very fast and minimise system resource then polars seems a better choice.

[@samuelswatson]

To me the appeal is the coherence of the API and the superior execution model. But the ecosystem disadvantages associated with using a much less popular library are substantial.

[@signoc1964]

@@samuelswatson but polars has a to_pandas() method, so the disadvantages is easily overcome, so its more like if you your doing simple things, then its unneccesary to bring in polars. We replaced a lot advanced elt(not etl) with polars. 16 000 lines of sql code done with the main transfroms done in polars instead, for this task it's excellent and translated really well, and a lot of stuff is easier to to in polars than in sql for example. Doing the same in pandas is a nightmare. Translating advanced sql code to pandas is a hard job.

[@samuelswatson]

​@@signoc1964 That seems to me to be the best use case for Polars (replacing complex SQL in transformation pipelines, especially because of its composability), so it's cool to hear another testimonial for its success in that context.

[@smellypunks]

It is a shame that the lazy API is so entangled into the API. Might be nice to write generic code which then has the option to switch on the lazy API with one single change. I don't like the idea of having to rewrite the whole codebase to switch between lazy and eager. I question if that was a good design decision from polars. - Side note please always upload videos in 1080p

[@ShawhinTalebi]

Here's my solution: cmd+f "scan_" replace with "read_" 😂 P.S. I'm on Mac

[@ravishmahajan9314]

Can Polars replace pyspark Or hadoop?

[@TheDataEntrepreneurs]

Good question. Here’s a response from Ben. “I’m not entirely sure tbh. i'm pretty sure pyspark is more scalable (e.g. > 1 TB data), but polars is better for data processing on your local machine (e.g. < 1 TB). i don't think Polars has so much stuff yet like pyspark does for distributed computing, whereas that is pretty much what pyspark was built for afaik.”

[@Dmitrii-q6p]

man, we can read. why read everything on the screen?

[@DarrenSaw]

Pandas is a massive mess. It's very easy to write very poor code in Pandas but to write it well is not that intuitive, Matt Harrison has written some great stuff, but it's not that easy to learn. Polars is way better and improving all the time. It's much easier to write and way quicker. The lazy API is a thing of beauty.

[@TheDataEntrepreneurs]

I'm looking forward to using Polars more in my own workflow -Shaw

[@MartyAckerman310]

I agree, Pandas' learning curve was steeper for me than R. But I've kind of settled on a consistent workflow(.loc[:,['col']] instead of ['col'], and dotchaining) that minimizes the surprises.

[@signoc1964]

One problem with polars though is that "pandas" developers then to write "polars" code like they write pandas code, and to some extent it is possible which gives people a bad example, since a couple of those. Polars becomes like pandas then executing in serial instead of parallell.