DEP: Deprecate the normed argument to histogramdd to match histogram - #11397

The main problem with deprecating old keywords is that there is no way for folks who want to maintain compatibility with old numpy to use the new keywords. I like having a compatible set, but I think it will be a long time before we can remove any old arguments.

Yep, I don't expect histogramdd::normed to be remove in a long time, if ever. There's probably an argument to removing histogram::normed though, since that's actively broken.

I'm thinking that in a couple releases we promote the PendingDeprecationWarning here to DeprecationWarning, and then probably leave it alone for a very long time

@charris: Too late for 1.15 now that the rc is out?

I'm skeptical of deprecating normed, it has likely been used by many people over the years and this will just lead to code churn. Would it not serve as well to simply leave it as an alias for density. That would not be quite as clean as removing it at some point, but would avoid annoying people for small reason.

Will PendingDeprecationWarning even create any noise for people?

Probably not.

@rgommers Thoughts?

@charris I agree that deprecating normed isn't a good idea. Just document it as an alias, and leave it as is.

This would anyway be my opinion I think, since we preferably shouldn't deprecate things for mostly cosmetic reasons. But in this case, there's a long history of us messing in bad ways with histogram (the normed, density and new keywords), which is an extra reason not to do that again.

@eric-wieser Let's just remove the deprecation. If we are never going to remove the keyword there is no point in deprecating it.

If we are never going to remove the keyword there is no point in deprecating it.

I don't agree with this - it's still a method to dictate the "one obvious way to do it" upon users writing new code, without breaking those maintaining old code.

Either way, I think introducing the density argument is a net positive however we handle normed, so I'll spin off a separate PR without the deprecation, and leave this one up in case we want it in future

I don't agree with this - it's still a method to dictate the "one obvious way to do it" upon users writing new code, without breaking those maintaining old code.

We have a long-standing policy of deprecating for two releases, then removing. There is nothing wrong with a doc-only deprecation, and it also clearly signal what the one correct way is.

Closing in favor of #11529, which has been merged.

We have a long-standing policy of deprecating for two releases, then removing.

Is this formalized anywhere? If not, perhaps it should be.

We should probably have a deprecation NEP.

There was a policy on the old Trac somewhere, written originally by @rkern IIRC. Our current docs don't have it.

We should probably have a deprecation NEP.

I can volunteer to (co-)write such a NEP. It should be broader than the old text I think; also what are and aren't good reasons for deprecation, etc.

Reopening with an incremental diff (which can't be pushed when it's closed), in case we come back to this as an example after writing the NEP. I'd like a stronger way to check that I'm not using inadvisable-but-non-deprecated features/apis without having to read the docs for every function. Perhaps DeprecationWarning is a poor way to indicate that, and we should introduce some internal warning type.

Can we close this?

Sure, not worth arguing about this