[Numpy-discussion] np.{bool,float,int} deprecation

[Sebastian Berg]

On Fri, 2020-12-11 at 11:35 +0100, Ralf Gommers wrote:
> On Thu, Dec 10, 2020 at 9:00 PM Sebastian Berg <  
> sebastian at sipsolutions.net>
> wrote:

<snip>

> 
> Just deprecation `np.int` may make sense. That will already raise
> awareness, and leaving `np.float` as-is may prevent a lot of churn.
> And we
> could then still deprecate `np.float` later. I also don't feel
> strongly
> about `float` either way though.
> 
> I'm not sure why you'd specifically touch `long`, it's not really
> relevant
> and it's not a builtin.
> 

`np.long is np.int is int` as it was a builtin on Python 2. But it
looks like a C-long.
In `dtype=` usage it actually ends up being a C-long (but it might even
be nice to consider modifying the default `int` on windows at some
point. At that point the "long" alias would be very confusing).

OTOH, right now the only way to spell C-long is with `np.int_` which
doesn't help.

Cheers,

Sebastian 




> Cheers,
> Ralf
> 
> To be honest, I don't mind either way, so any stronger opinion will
> tip
> > the scale for me personally (my default currently is to update the
> > release notes to recommend the more descriptive names).
> > 
> > There are probably more doc updates that would be nice, I will
> > suggest
> > updating a separate issue for that.
> > 
> > 
> > > Right now, my main take-away from the discussion is that it would
> > > be
> > > > good to clarify the release notes a bit more.
> > > > 
> > > > Using `float` for a dtype seems fine to me, but I prefer
> > > > mentioning
> > > > `np.float64` over `np.float_`.
> > > > For integers, I wonder if we should also suggest `np.int64`,
> > > > even –
> > > > or
> > > > because – if the default integer on many systems is currently
> > > > `np.int_`?
> > > > 
> > > 
> > > I agree. I think we should recommend sane, descriptive names that
> > > do
> > > the
> > > right thing. So ideally we'd have people spell their dtype
> > > specifiers
> > > as
> > >   dtype=bool  # or np.bool
> > >   dtype=np.float64
> > >   dtype=np.int64
> > >   dtype=np.complex128
> > > The names with underscores at the end make little sense from a UX
> > > perspective. And the C equivalents (single/double/etc) made sense
> > > 15
> > > years
> > > ago, but with the user base of today - the majority of whom will
> > > not
> > > know C
> > > fluently or at all - also don't make too much sense.
> > > 
> > > The `dtype=int` or `dtype=np.int_` behaviour flopping between 32
> > > and
> > > 64
> > > bits is likely to be a pitfall much more often than it is what
> > > the
> > > user
> > > actually needs, so shouldn't be recommended and probably deserves
> > > a
> > > warning
> > > in the docs.
> > 
> > Right, there is one slight trickery because `np.intp` is often a
> > great
> > integer dtype to use, because it is the integer that NumPy uses for
> > all
> > things related to indexing and array sizes.
> > (I would be happy to dig out my PR making `np.intp` the default
> > NumPy
> > integer.)
> > 
> > Cheers,
> > 
> > Sebastian
> > 
> > 
> > > 
> > > Cheers,
> > > Ralf
> > > 
> > > 
> > > > 
> > > > > 
> > > > > 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.
> > > > > 
> > > > > 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):
> > > > > https://jax.readthedocs.io/en/latest/type_promotion.html
> > > > 
> > > > 
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> > 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.python.org/pipermail/numpy-discussion/attachments/20201211/4fdffa4c/attachment.sig>