Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the pd.DataFrame and pd.Series extension methods #368

Open
jorenham opened this issue Dec 4, 2024 · 0 comments
Open

Remove the pd.DataFrame and pd.Series extension methods #368

jorenham opened this issue Dec 4, 2024 · 0 comments
Labels
breaking change Backwards incompatible contrib Integration with 3rd party packages
Milestone

Comments

@jorenham
Copy link
Owner

jorenham commented Dec 4, 2024

Currently, if pandas is installed, import lmo automatically registers the dataframe- and series accessors (pandas docs). There are several major issues with this approach:

  • It significantly slows down import lmo if pandas is installed, even if the user doesn't import pandas. If I remember correctly from a benchmark I did a while back, this is responsible for the majority of the runtime of an (initial) import lmo call.
  • It's impossible to statically type: Static type-checkers cannot "be told" that pd.DataFrame and pd.Series actually have the l_* methods, let alone their exact signatures. The only workaround is to manually cast the dataframe or series instances to lmo.contrib.pandas.{DataFrame,Pandas}, which is very annoying.
  • There are better alternatives:
    • Series.l_{}(...) just calls lmo.l_{}(_, ...) on the instance, and in the "plural" cases, rewraps it as a Series with a new "r" index. Once Support __array_ufunc__ in lmo.l_(loc|scale|variation|skew|kurtosis)  #184 is implemented, this could (for the most part) also be done with a simple lmo.l_{}, which is a better alternative.
    • DataFrame.l_{}(...) is basically an alias for DataFrame.apply(lmo.l_{}, ...), so almost as easy to do it manually.
@jorenham jorenham added contrib Integration with 3rd party packages breaking change Backwards incompatible labels Dec 4, 2024
@jorenham jorenham added this to the v1.0.0 milestone Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change Backwards incompatible contrib Integration with 3rd party packages
Projects
None yet
Development

No branches or pull requests

1 participant