Extremely lightweight and extensible compatibility layer between dataframe libraries!
- Full API support: cuDF, Modin, pandas, Polars, PyArrow
- Lazy-only support: Dask
- Interchange-level support: DuckDB, Ibis, Vaex, anything which implements the DataFrame Interchange Protocol
Seamlessly support all, without depending on any!
- ✅ Just use a subset of the Polars API, no need to learn anything new
- ✅ Zero dependencies, Narwhals only uses what the user passes in so your library can stay lightweight
- ✅ Separate lazy and eager APIs, use expressions
- ✅ Support pandas' complicated type system and index, without either getting in the way
- ✅ 100% branch coverage, tested against pandas and Polars nightly builds
- ✅ Negligible overhead, see overhead
- ✅ Let your IDE help you thanks to full static typing, see typing
- ✅ Perfect backwards compatibility policy, see stable api for how to opt-in
Get started!
Table of contents
- pip (recommended, as it's the most up-to-date)
pip install narwhals
- conda-forge (also fine, but the latest version may take longer to appear)
conda install -c conda-forge narwhals
There are three steps to writing dataframe-agnostic code using Narwhals:
-
use
narwhals.from_native
to wrap a pandas/Polars/Modin/cuDF/PyArrow DataFrame/LazyFrame in a Narwhals class -
use
narwhals.to_native
to return an object to the user in its original dataframe flavour. For example:- if you started with pandas, you'll get pandas back
- if you started with Polars, you'll get Polars back
- if you started with Modin, you'll get Modin back (and compute will be distributed)
- if you started with cuDF, you'll get cuDF back (and compute will happen on GPU)
- if you started with PyArrow, you'll get PyArrow back
See the tutorial for several examples!
- Do you maintain a dataframe-consuming library?
- Do you have a specific Polars function in mind that you would like Narwhals to have in order to make your work easier?
If you said yes to both, we'd love to hear from you!
See roadmap discussion on GitHub for an up-to-date plan of future work.
Join the party!
- altair
- hierarchicalforecast
- marimo
- panel-graphic-walker
- plotly
- pymarginaleffects
- py-shiny
- rio
- scikit-lego
- scikit-playtime
- tabmat
- tea-tasting
- timebasedcv
- tubular
- vegafusion
- wimsey
Feel free to add your project to the list if it's missing, and/or chat with us on Discord if you'd like any support.
Narwhals is 100% independent, community-driven, and community-owned. We are extremely grateful to the following organisations for having provided some funding / development time:
If you contribute to Narwhals on your organization's time, please let us know. We'd be happy to add your employer to this list!
Narwhals has been featured in several talks, podcasts, and blog posts:
-
Talk Python to me Podcast Ahoy, Narwhals are bridging the data science APIs
-
Python Bytes Podcast Episode 402, topic #2
-
Super Data Science: ML & AI Podcast
Narwhals: For Pandas-to-Polars DataFrame Compatibility -
Sample Space Podcast | probabl
How Narwhals has many end users ... that never use it directly. - Marco Gorelli -
The Real Python Podcast Narwhals: Expanding DataFrame Compatibility Between Libraries
-
Pycon Lithuania
Marco Gorelli - DataFrame interoperatiblity - what's been achieved, and what comes next? -
Pycon Italy
How you can write a dataframe-agnostic library - Marco Gorelli -
Polars Blog Post
Polars has a new lightweight plotting backend -
Quansight Labs blog post (w/ Scikit-Lego)
How Narwhals and scikit-lego came together to achieve dataframe-agnosticism
Thanks to Olha Urdeichuk for the illustration!