Re: Change return type of Histogramdd and Histogram

--===============0893156035620231967==
Content-Type: multipart/alternative; boundary="0000000000003ac93f0652bb6976"

--0000000000003ac93f0652bb6976
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 25, 2026 at 8:12=E2=80=AFAM Joseph Mehdiyev via NumPy-Discussio=
n <
[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 he=
lp
> 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 thi=
s
> 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=3D%22np.histogramdd%22+language%3APython&type=
=3Dcode

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 an=
d
> may be forgotten/uncared for again. is it possible to add a related tag o=
n
> that github issue or I may open a PR about it so this will be surely look=
ed
> 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]
>

--0000000000003ac93f0652bb6976
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 25,=
 2026 at 8:12=E2=80=AFAM Joseph Mehdiyev via NumPy-Discussion &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; Do =
you have any responses to the arguments Ralf made back in 2018 in favor<br>
of doing nothing?<br>
I was looking at a couple of issues on histograms specifically, there are m=
any issues, features, optimizations that are present in histogramdd and not=
 in histogram and vice versa. I think histogram should just call histogramd=
d internally in future as I do not see any reasons (other than legacy issue=
s like this one) why they should behave differently. Would help maintainanc=
e greatly too.<br>
<br>
About the Ralf&#39;s, I am not sure if some consumers&#39; code would be br=
oken (if so, I think it would be very rare) just by this change, but isn&#3=
9;t this behaviour easy to implement user-side anyways? They can implement =
this behaviour if they deem this necessary. I am not an experienced develop=
er so I might be wrong though.<br>
<br></blockquote><div><br></div><div>The issue is the migration story. It&#=
39;s very hard to tell what use cases might break, but changing the output =
dtype of a function can definitely break things.</div><div><br></div><div>J=
ust 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:</d=
iv><div><br></div><div><a href=3D"https://github.com/search?q=3D%22np.histo=
gramdd%22+language%3APython&amp;type=3Dcode">https://github.com/search?q=3D=
%22np.histogramdd%22+language%3APython&amp;type=3Dcode</a><br></div><div><b=
r></div><div>Many look like they do math with the results and I couldn&#39;=
t certainly see returning floats vs integers causing issues.</div><div><br>=
</div><div>This is why Ralf said back in 2018 that changing the output dtyp=
e immediately &quot;seems like a no-go, taking such risks isn&#39;t justifi=
ed by a minor inconsistency&quot;. I agree with him for the reasons I just =
outlined.</div><div><br></div><div>So if we can&#39;t change the output dty=
pe, how do we do the transition? We could add new keyword arguments as outl=
ined in the thread back in 2018, but the keywords complicate the NumPy API =
and aren&#39;t very useful unless we can eventually make them the default, =
which necessarily (I think?) requires generating warnings for correct use-c=
ases today.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
&gt; Add it to the pile of issues to think about for NumPy 3.0, if we ever<=
br>
decide to do that?<br>
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?<br></blockquote><div><br></div><div>No, there isn&#39;t but th=
ere probably should be. There are unfortunately a large number of organizat=
ional tasks that are on the TODO pile for NumPy&#39;s issue and PR backlog.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
NumPy-Discussion mailing list -- <a href=3D"mailto:numpy-discussion@python.=
org" target=3D"_blank">[email protected]</a><br>
To unsubscribe send an email to <a href=3D"mailto:numpy-discussion-leave@py=
thon.org" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://mail.python.org/mailman3//lists/numpy-discussion.python.=
org" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mailman3/=
/lists/numpy-discussion.python.org</a><br>
Member address: <a href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a><br>
</blockquote></div></div>

--0000000000003ac93f0652bb6976--

--===============0893156035620231967==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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]

--===============0893156035620231967==--