-
Pandas
Flexible and powerful data analysis / manipulation library for Python, providing labeled data structures similar to R data.frame objects, statistical functions, and much more
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Personally polars' strictness is making me think about situations when in pandas we end up with object dtype, which we should probably avoid. Here's an example: https://github.com/pandas-dev/pandas/issues/50887 (polars would just error in such a case, which I think is the correct thing to do)
There is a typing effort that is led by some core members (unfortunately none of them takes part today). You can check the stubs package out at https://github.com/pandas-dev/pandas-stubs. I am not really familiar with the progress there
There's an issue here about that https://github.com/scikit-learn/scikit-learn/discussions/25450
you've sort of become victims of your own success: as another pandas dev mentioned, you want to preserve backwards compatibility and this significantly complicates any restructuring. I'm sympathetic and am not sure what the best solution here would be. I had this idea last night but i'm not sure I like this approach either.
I'm not sure if there is already support for all Arrow complex types in pandas 2.0, but we have some support of lists for sure, and I think structs too. For the bigquery part, I think you can ask this to the developers of this repo: https://github.com/googleapis/python-bigquery-pandas We basically wrap that library with the read_gbq() function. but there is not much big query specific in pandas other than that, so not much idea.