<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 1:07 PM Aaron Meurer <<a href="mailto:asmeurer@gmail.com">asmeurer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 9, 2020 at 9:41 AM Sebastian Berg<br>
<<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>> wrote:<br>
><br>
> On Mon, 2020-12-07 at 14:18 -0700, Aaron Meurer wrote:<br>
> > Regarding np.bool specifically, if you want to deprecate this, you<br>
> > might want to discuss this with us at the array API standard<br>
> > <a href="https://github.com/data-apis/array-api" rel="noreferrer" target="_blank">https://github.com/data-apis/array-api</a> (which is currently in RFC<br>
> > stage). The spec uses bool as the name for the boolean dtype.<br>
> ><br>
> > Would it make sense for NumPy to change np.bool to just be the<br>
> > boolean<br>
> > dtype object? Unlike int and float, there is no ambiguity with bool,<br>
> > and NumPy clearly doesn't have any issues with shadowing builtin<br>
> > names<br>
> > in its namespace.<br>
><br>
> We could keep the Python alias around (which for `dtype=` is the same<br>
> as `np.bool_`).<br>
><br>
> I am not sure I like the idea of immediately shadowing the builtin.<br>
> That is a switch we can avoid flipping (without warning); `np.bool_`<br>
> and `bool` are fairly different beasts? [1]<br>
<br>
NumPy already shadows a lot of builtins, in many cases, in ways that<br>
are incompatible with existing ones. It's not something I would have<br>
done personally, but it's been this way for a long time.<br></blockquote><div><br></div><div>It may be defensible to keep np.bool as an alias for Python's bool even when we remove the other aliases.</div><div><br></div><div>np.int_ and np.float_ have fixed precision, which makes them somewhat different from the builtin types. NumPy has a whole bunch of different precisions for integer and floats, so this distinction matters.</div><div><br></div><div>In contrast, there is only one boolean dtype in NumPy, which matches Python's bool. So we wouldn't have to worry, for example, about whether a user has requested a specific precision explicitly. This comes up in issues like type-promotion where libraries like JAX and PyTorch have special case logic for most Python types vs NumPy dtypes (but booleans are the same for both):</div><div><a href="https://jax.readthedocs.io/en/latest/type_promotion.html">https://jax.readthedocs.io/en/latest/type_promotion.html</a><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Aaron Meurer<br>
<br>
> OTOH, if someone wants to entertain switching... It could be<br>
> interesting to see how (unfixed) downstream projects react to it.<br>
><br>
> One approach would be:<br>
><br>
> * Go ahead for now (deprecate)<br>
> * Add a FutureWarning at some point that we _will_ start to export<br>
>   `np.bool` again (but `from numpy import *` is a problem?)<br>
> * Aim to make `np.bool is np.bool_` at some point in the (far) future.<br>
><br>
> It is multi-step (and I recall opinions that multi-step is bad).<br>
> Although, I think the main argument against it was to not force users<br>
> to modify code more than once.  And I do not think that happens here.<br>
><br>
> Of course we could use the `FutureWarning` right away, but I don't mind<br>
> taking it slow.<br>
><br>
> Cheers,<br>
><br>
> Sebastian<br>
><br>
><br>
><br>
> [1] I admit, probably almost nobody would notice. And usually using a<br>
> Python `bool` is better...<br>
><br>
><br>
> ><br>
> > Aaron Meurer<br>
> ><br>
> > On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias <<a href="mailto:jni@fastmail.com" target="_blank">jni@fastmail.com</a>><br>
> > wrote:<br>
> > > Hi all,<br>
> > ><br>
> > > At the prodding [1] of Sebastian, I’m starting a discussion on the<br>
> > > decision to deprecate np.{bool,float,int}. This deprecation broke<br>
> > > our prerelease testing in scikit-image (which, hooray for rcs!),<br>
> > > and resulted in a large amount of code churn to fix [2].<br>
> > ><br>
> > > To be honest, I do think *some* sort of deprecation is needed,<br>
> > > because for the longest time I thought that np.float was what<br>
> > > np.float_ actually is. I think it would be worthwhile to move to<br>
> > > *that*, though it’s an even more invasive deprecation than the<br>
> > > currently proposed one. Writing `x = np.zeros(5, dtype=int)` is<br>
> > > somewhat magical, because someone with a strict typing mindset<br>
> > > (there’s an increasing number!) might expect that this is an array<br>
> > > of pointers to Python ints. This is why I’ve always preferred to<br>
> > > write `dtype=<a href="http://np.int" rel="noreferrer" target="_blank">np.int</a>`, resulting in the current code churn.<br>
> > ><br>
> > > I don’t know what the best answer is, just sparking the discussion<br>
> > > Sebastian wants to see. ;) For skimage we’ve already merged a fix<br>
> > > (even if it is one of dubious quality, as Stéfan points out [3] ;),<br>
> > > so I don’t have too much stake in the outcome.<br>
> > ><br>
> > > Juan.<br>
> > ><br>
> > > [1]:<br>
> > > <a href="https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739334463" rel="noreferrer" target="_blank">https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739334463</a><br>
> > > [2]: <a href="https://github.com/scikit-image/scikit-image/pull/5103" rel="noreferrer" target="_blank">https://github.com/scikit-image/scikit-image/pull/5103</a><br>
> > > [3]:<br>
> > > <a href="https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739368765" rel="noreferrer" target="_blank">https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739368765</a><br>
> > > _______________________________________________<br>
> > > NumPy-Discussion mailing list<br>
> > > <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> > > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
> > _______________________________________________<br>
> > NumPy-Discussion mailing list<br>
> > <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> > <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@python.org" target="_blank">NumPy-Discussion@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div></div>