-
Notifications
You must be signed in to change notification settings - Fork 92
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
api: "unstable" features #1367
Comments
No need to be sorry, I think #1290 was not even discussed fully (e.g. in which way we want to implement rolling for pyarrow backend). Regarding how to mark features as unstable, which options do we have? Adding a warning/disclaimer in the docstrings and docs is the bare minimum, aside that:
I would say this second option could be a compromise? |
thanks! the second one could work - we could define a |
Is this decided then?: "define a NarwhalsUnstableWarning class, and advise users to silence warnings of that class if they're OK with using an experimental feature" |
Yeah I think this is probably the best way to go about it, thanks for the discussion Are you interested in adding EDIT: - Dea said on stream that she'd be happy to take this on, so I'll assign it to her |
So, the |
i think you're right - i'll change the assignment then, once we get that in we can ship ewm_mean too 🚀 |
I'm slightly hesitant about how to merge #1298 and #1290 - rolling_mean is marked as unstable in Polars. ewm_mean isn't, but follows the api kind of API style
I do think we should merge them, I just think we need a way to signal that we won't make the same kinds of promises for them as we do for the rest of the API in
stable.v1
So, I'm tempted to say:
I'm sorry for the delay here in merging these PRs
The text was updated successfully, but these errors were encountered: