3 ms·

I've only heard about Ibis maybe three times in the past two years and I pay pretty close attention to the space. If Ibis moves away from pandas, then it just m

I've only heard about Ibis maybe three times in the past two years and I pay pretty close attention to the space. If Ibis moves away from pandas, then it just means that I am less likely to try Ibis because there is no bridge. Sure, hip new frameworks are moving away from pandas/numpy, but I'll wait 5 years for the dust to settle here while the compatibility and edge cases sort themselves out. The pydata/numfocus ecosystem is extensive. It's just tabular data. So what if I have to wait a few more milliseconds to get my result.

cpcloud 2y ago
Sounds like a solid plan. No reason to incur switching costs if things are working! I think you're misunderstanding what "removing pandas" means. You can still compute on DataFrames, it'll just be with something other than Pandas itself, probably DuckDB, Polars, or DataFusion. So, the bridge was there, is there, and isn't going anywhere.
- deleted 2y ago
  [deleted]
- halfcat 2y ago
  > I think you're misunderstanding what "removing pandas" means. Maybe it’s in the messaging, like the “Farewell Pandas” part?
  - cpcloud 2y ago
    Feel free to put up a pull request with an alternate title that you feel communicates the message in a more accurate way!
codyvoda 2y ago
> If Ibis moves away from pandas, then it just means that I am less likely to try Ibis because there is no bridge. the bridge is that Ibis accepts pandas as input and has a `to_pandas()` method as output Ibis also still depends on pandas (and thus numpy) internally. also, Ibis was created by the creator of pandas, and the lead developer (and other contributors) have also worked on pandas. the Ibis team understands pandas and the broader Python data ecosystem very well > It's just tabular data. So what if I have to wait a few more milliseconds to get my result. usually as scale grows, milliseconds -> seconds -> minutes -> hours -> days. at some point along the way having a dataframe library that can scale up without rewriting your code might be useful. but if you're dealing with small tabular data and pandas meets your needs, it's a great library to use and stick with!

cpcloud 2y ago

Sounds like a solid plan. No reason to incur switching costs if things are working! I think you're misunderstanding what "removing pandas" means. You can still compute on DataFrames, it'll just be with something other than Pandas itself, probably DuckDB, Polars, or DataFusion. So, the bridge was there, is there, and isn't going anywhere.

deleted 2y ago
[deleted]
halfcat 2y ago
> I think you're misunderstanding what "removing pandas" means. Maybe it’s in the messaging, like the “Farewell Pandas” part?
- cpcloud 2y ago
  Feel free to put up a pull request with an alternate title that you feel communicates the message in a more accurate way!

codyvoda 2y ago

> If Ibis moves away from pandas, then it just means that I am less likely to try Ibis because there is no bridge. the bridge is that Ibis accepts pandas as input and has a `to_pandas()` method as output Ibis also still depends on pandas (and thus numpy) internally. also, Ibis was created by the creator of pandas, and the lead developer (and other contributors) have also worked on pandas. the Ibis team understands pandas and the broader Python data ecosystem very well > It's just tabular data. So what if I have to wait a few more milliseconds to get my result. usually as scale grows, milliseconds -> seconds -> minutes -> hours -> days. at some point along the way having a dataframe library that can scale up without rewriting your code might be useful. but if you're dealing with small tabular data and pandas meets your needs, it's a great library to use and stick with!