You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was initially hesitant about adding IO methods, the idea being "users provide their own dataframe, we just deal with how to process it", but we already have from_dict, and ImperialCollegeLondon/pycsvy#83 and Temporian look like good use cases for read_csv
pandas and Polars each have dozens of read_csv methods...so we may need to careful here about which ones we add, and perhaps only start with the most common ones
But then, what to do with the already imported pandas...? If you are importing it, you might as well use it for I/O
The only major reason to have an I/O support (that I can think of) would be if you would want to replace an entire "narwhals workflow/script" with one setting.
I was initially hesitant about adding IO methods, the idea being "users provide their own dataframe, we just deal with how to process it", but we already have from_dict, and ImperialCollegeLondon/pycsvy#83 and Temporian look like good use cases for
read_csv
pandas and Polars each have dozens of
read_csv
methods...so we may need to careful here about which ones we add, and perhaps only start with the most common onesThe api would be something like
We could do:
nw.read_csv
: this is eager-only and always returnsnw.DataFrame
nw.scan_csv
: this is the most generic one, and returnsnw.LazyFrame
if possible (e.g. Polars), elsenw.DataFrame
Alternatives
Keep the status-quo: users are responsible for doing their own IO
The text was updated successfully, but these errors were encountered: