

0 / 2 embers
0 / 3000 xp
click for more info
Complete a lesson to start your streak
click for more info
Difficulty: 4
click for more info
Not enough gems
Cost: 6 gems
1: Polars
incomplete
2: Basic Operations
incomplete
3: Polars vs. Pandas
incomplete
4: Expression-Based Operations
incomplete
5: Lazy vs. Eager Execution
incomplete
6: No Index
incomplete
7: Filtering With No Index
incomplete
8: Index Alternatives
incomplete
9: Sorting
incomplete
10: Sorting Footguns
incomplete
11: Time-Based Operations
incomplete
12: Parquet
incomplete
13: Parquet With Polars
incomplete
Back
ctrl+,
Next
ctrl+.
This lesson's interactive features are locked, please to keep using them
Polars has two execution modes: eager and lazy.
Click to play video
In eager mode (the default), operations run immediately:
df = pl.read_csv("players.csv")
result = df.filter(pl.col("level") > 25)
Which, to be fair, is what you'd probably expect from most Python code.
For higher performance, enter lazy mode with df.lazy(), then chain your operations and execute the query plan with .collect():
df = pl.read_csv("players.csv")
result = (
df.lazy() # Start lazy mode
.filter(pl.col("level") > 25)
.select(["player", "level"])
.collect() # Execute the query
)
Lazy mode lets Polars optimize the entire query before it runs. By the time .collect() is called, Polars understands the whole pipeline, not just one step at a time.
For large datasets, this can make a huge difference.
If you're writing code to reuse or deploy, lazy mode is often better. If you're working interactively, prototyping, or just doing one-off analysis, eager mode is fine.
SnackStack's export of device status alerts is getting large enough that the analytics team wants the report built lazily.
Complete the build_lazy_alert_report function. It accepts a Polars DataFrame of device alerts and returns a new report DataFrame.