-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
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
Deprecate: level
parameter for aggregations in DataFrame and Series
#39983
Comments
instructions which u linked are accurate |
I am personally fine with deprecating this keyword (I never use(d) myself in practice). Pinging some more people since it's a quite prominent keyword affecting many functions @pandas-dev/pandas-core @pandas-dev/pandas-triage |
I would be +1 if we were removing a seldomly used keyword in exchange for a significant simplification in the code; but my understanding is that we would be removing syntactic sugar which is implemented in a relatively straightforward way. Not sure this is worth the potential disruption to anybody who is using (and liking) this. I myself would be tempted to use it... now I know it exists ;-) |
+1 to deprecate. Seems like a nice API clean up, and I think the zen of Python makes a lot of sense when it says that there should be one and preferrably only on obvious way to do things. |
2c: never noticed these, so groupby is probably the "one right way to do it". However, the bloat in Pandas IMO more lies in a redundancy of verbs rather than parameters, so I'm not convinced that you gain a whole lot by this. One key question is: how clear is I also note that the docs are currently wrong in pd.DataFrame.sum etc: |
Right. I think the best way to document syntactic sugar is to typically just describe what it replaces. E.g. "equivalent to |
#40660 is a good argument pro deprecating this. |
#40788 looks like another |
This is actually a duplicate of #40660 |
Apologies if this is the wrong place to discuss this, please let me know and I'll gladly move it around. I only recently updated to 1.3 and noticed the FutureWarning related to this change. I would like to request that, in light of this change, that Setup:
Prior to 1.3 I would use the following to sum up data from smaller regions ('001', '002', etc) to bigger regions (A, B):
which, as of 1.3 I suppose should become something like
HOWEVER,
Am I missing something? Is there an easier way to do this? Thanks! |
For
sum
,prod
,count
, etc. there is a parameterlevel
which is internally rewritten intogroupby
.I propose that the
level
parameter for these aggregations be deprecated and instead recommend to users that they use thegroupby
syntax.The functions that would be affected are:
I believe this list is comprehensive.
The text was updated successfully, but these errors were encountered: