On Mon, May 25, 2026 at 8:12 AM Joseph Mehdiyev via NumPy-Discussion < [email protected]> wrote:
> > Do you have any responses to the arguments Ralf made back in 2018 in > favor > of doing nothing? > I was looking at a couple of issues on histograms specifically, there are > many issues, features, optimizations that are present in histogramdd and > not in histogram and vice versa. I think histogram should just call > histogramdd internally in future as I do not see any reasons (other than > legacy issues like this one) why they should behave differently. Would help > maintainance greatly too. > > About the Ralf's, I am not sure if some consumers' code would be broken > (if so, I think it would be very rare) just by this change, but isn't this > behaviour easy to implement user-side anyways? They can implement this > behaviour if they deem this necessary. I am not an experienced developer so > I might be wrong though. > > The issue is the migration story. It's very hard to tell what use cases might break, but changing the output dtype of a function can definitely break things. Just to gauge the blast radius, I did a github code search just now for uses of `np.histogramdd` in Python code, producing 5300 open source results: https://github.com/search?q=%22np.histogramdd%22+language%3APython&type=code Many look like they do math with the results and I couldn't certainly see returning floats vs integers causing issues. This is why Ralf said back in 2018 that changing the output dtype immediately "seems like a no-go, taking such risks isn't justified by a minor inconsistency". I agree with him for the reasons I just outlined. So if we can't change the output dtype, how do we do the transition? We could add new keyword arguments as outlined in the thread back in 2018, but the keywords complicate the NumPy API and aren't very useful unless we can eventually make them the default, which necessarily (I think?) requires generating warnings for correct use-cases today. > > > Add it to the pile of issues to think about for NumPy 3.0, if we ever > decide to do that? > I guess this is the safest option. Although this will take a long time and > may be forgotten/uncared for again. is it possible to add a related tag on > that github issue or I may open a PR about it so this will be surely looked > for in 3.0? > No, there isn't but there probably should be. There are unfortunately a large number of organizational tasks that are on the TODO pile for NumPy's issue and PR backlog. > _______________________________________________ > NumPy-Discussion mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3//lists/numpy-discussion.python.org > Member address: [email protected] >
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
