8000 arr.astype(None) converts to float64 · Issue #18774 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

arr.astype(None) converts to float64 #18774

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ivirshup opened this issue Apr 14, 2021 · 4 comments
Open

arr.astype(None) converts to float64 #18774

ivirshup opened this issue Apr 14, 2021 · 4 comments

Comments

@ivirshup
Copy link
Contributor

arr.astype(None) converts arr to float64. I'd expect this to either error, or do nothing. Doc string says:

dtype : str or dtype
    Typecode or data-type to which the array is cast.

Which makes it seem like it should error.

Reproducing code example:

import numpy as np

assert np.ones(3, dtype=np.float32).astype(None).dtype != np.float64

Error message:

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-17-115497a92e9f> in <module>
----> 1 assert np.ones(3, dtype=np.float32).astype(None).dtype != np.float64

AssertionError: 

NumPy/Python version information:

1.20.2 3.8.6 (default, Nov 20 2020, 18:29:40) 
[Clang 12.0.0 (clang-1200.0.32.27)]
@nschloe
Copy link
Contributor
nschloe commented Apr 14, 2021

Related to #10405. I guess in the case of None, numpy just takes the default dtype which is np.float64 (np.asarray([]).dtype).

@seberg
Copy link
Member
seberg commented Apr 14, 2021

Its true, we could c A4A3 hange the way we use None everywhere by deprecating it in PyArray_DescrConverter (or the other variant). It would need some careful review whether that is actually right. None is pretty typical for denoting "default" and it does exactly that here. Except that using a "default" is a bit strange for astype specifically. So I think if we want to change it, we likely should only do it for a few of the calls (someone should manually go through all of them and see, it may be very few).

@ivirshup
Copy link
Contributor Author

None is pretty typical for denoting "default" and it does exactly that here

I'm not sure if it's exactly that, since it's a required positional argument so there is no default. The "inspiration" for this issue was that I had None for a default argument, with a if dtype is None: dtype = np.float32 later in the body. There was a logic bug, and that wasn't being set, leading to that assignment not happening.

Except that using a "default" is a bit strange for astype specifically.

I think np.dtype may be a similar case, since np.dtype() errors, but np.dtype(None) == np.float64.

@seberg
Copy link
Member
seberg commented Apr 15, 2021

Right, it would be nice if someone wants to try the deprecation, I just have no idea how hard it is (basically, this means we try it and if the big downstream libraries are fine, we can likely get away with it). You are right that astype doesn't have a "default" (even if it had, the default should be to keep the old dtype...).

So I personally agree that it would be a good change, the only thing I am not sure about is the np.array([]).dtype itself. Making that an error (because no dtype is discovered so it would need to be provided) might just be a bit unpractical or just more difficult then most of the other places, where None is very hard to run into.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0