Pre-Release of Polars 2.0

143

kkomape about 3 hours ago 27 commentsRead Article on pola.rs

ES version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

64% Positive

Analyzed from 616 words in the discussion.

Discussion (27 Comments)Read Original on HackerNews

benrutter•about 2 hours ago

> We don’t aim to make a big feature release of Polars 2.0. In fact we hope it to be a boring experience for you. The reason we bump this major version is that we can get rid of design decisions made in the past that currently block us and then we want to change defaults to more sensible settings that will benefit a greater audience

I know this take reveals me as a very dull person, but I love seeing projects take semver seriously like this! Version bumps should really be about removing deprecated cruft rather than shiny new features.

I've used polars for a while now, and their focus on stability was a big part if convincing me to make the jump initially!

nicce•about 1 hour ago

> Version bumps should really be about removing deprecated cruft rather than shiny new features.

Can there be deprecated cruft without new features? :-D

dist-epoch•about 1 hour ago

That being said Polars is one of the few Python libraries from the hundreds I use that I need to read the notes of every minor release (eg 1.44 -> 1.45), because they tend to frequently deprecate, remove or change features.

Bluestein•about 2 hours ago

"Tranquil development" (vs. "hype-driven shipping") :)

arn3n•6 minutes ago

The decision to default to the streaming engine is really interesting. My intuition is that this would be slower than other data frame operations that are more parallelizable with batch processing, because streaming engines necessarily process rows sequentially. Is my intuition off/am I overestimating how much auto-parallelization polars does?

bluebarbet•5 minutes ago

What does this project have to do with Serbia? Are the developers in Belgrade?

bobson_dugnutt5•about 1 hour ago

I love polars. Did a lot of evangelizing in work to get people to give up pandas in favor of it.

anotherpaul•about 1 hour ago

I gave up pandas in favor of polars after someone at work did the same and I am very happy with it. Pandas API is just so much worse and much slower.

mgaunard•about 1 hour ago

Both have terrible syntax that make SQL look like the most readable thing ever.

gpugreg•5 minutes ago

You can query polars data frames with SQL: https://docs.pola.rs/api/python/stable/reference/expressions...

Unfortunately, polars does not support parameterized queries, so the risk of SQL injection is extremely high.

condwanaland•about 1 hour ago

Could not agree less. Ive always found SQL an unreadable mess but tools like polars and dplyr are such elegant ways to manipulate data.

Pandas is a mess though.

aquafox•about 1 hour ago

Coming from an R/dplyr background, I agree. Compare

df.select(

  pl.col("x"),
  (pl.col("w")/pl.col("z")).alias("y")

)

with

df |> select(x, y = w/z)

jcattle•9 minutes ago

R really is/was the superior traditional data science language. Python ecosystem is slowly catching up though.

ggplot vs matplotlib

dplyr vs pandas

And I loved that everything in RStudio was so easily inspectable. Have a huge dataframe? Just look at it right in your IDE.

orlp•16 minutes ago

    from polars import col as C

    df.select(C.x, y = C.w / C.z)

bobson_dugnutt5•about 1 hour ago

Fair point, but you can do something like

`df.select("x", y=pl.col.w/pl.col.z)`

bobson_dugnutt5•about 1 hour ago

What is it about polars syntax you don't like? The fact that is very verbose? At first I wasn't a fan, but over time I've grown to really like it. That never happened to me with pandas, always felt the syntax was messy

fzumstein•about 1 hour ago

I tend to agree. SQL may have been harder to write in the past (worse autocomplete than pandas/polars), but now that AI is writing the code, SQL is usually much easier to read. So DuckDB is another interesting alternative to pandas.

refactor_master•39 minutes ago

The cool thing about polars is that you can conditionally collect expressions over many layers of business logic, and then compute the result at the end. Doing this in SQL ends up in a hodgepodge of strings and trimmed ends to please the syntax. You can also pretty effortlessly write quite complex conditionals directly in polars, and bridge it easily to the surrounding python.

I find that SQL is only easier to read with minimal abstraction, but as soon as the project gets bigger SQL becomes an unwieldy island of different that has served its purpose after we’re done with reading/writing the data.

rfgplk•about 1 hour ago

Seeing "release will land in the following weeks" kind of immediately turns me off.

thibaut_barrere•about 1 hour ago

I like when large projects do that. This gives leeway for sister projects (eg wrappers) to anticipate, room for apps that use it intensively to test things out (release candidate etc), something which has really helped me in the past.

In that specific case I use a Polars wrapper in Elixir (called Explorer) all week long, and I am very happy they are giving us early hints.

marliechiller•about 1 hour ago

What is your understanding of a Pre-Release then?

dbdr•about 1 hour ago

Why?

irpap•about 1 hour ago

I assume because “land” is a word Claude would choose.

mgaunard•about 1 hour ago

Claude's wording (and knowledge) is based on what competent senior engineers would say.

tancop•29 minutes ago

It's the only good word here. "Drop" can also mean the opposite and anything else sounds too formal. Don't get me started on "release will release".