-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Typing support for dtypes #16545
Comments
For complex dtypes like Very little functionality is lost in the meantime if numpy functions that return arrays of |
This is really all I need, what is the issue? Anything I can do? |
Circling back around to this: another issue is that you can mutate an array's dtype in-place, e.g. >>> x = np.ones((2,), dtype=np.int64)
>>> x
array([1, 1])
>>> x.dtype = np.bool_
>>> x
array([ True, False, False, False, False, False, False, False, True,
False, False, False, False, False, False, False]) So if you tried to add types: x: np.ndarray[np.int64] = np.ones((2,), dtype=np.int64)
x.dtype = np.bool_ # Uh oh, the type is incorrect now. I imagine that most of the time people don't do that (and use views instead), which we could handle quite nicely in some cases with the right overload: T = TypeVar('T', bound=dtype)
class ndarray(...):
...
@overload
def view(self, dtype: T = ...) -> ndarray[T]: ... A practical solution might be to say "if you are going to set dtype, you are on your own", and ask that in such cases a user do x: np.ndarray[Any] = np.ones((2,), dtype=np.int64)
x.dtype = np.bool_ # Still ok Thoughts? |
I don't think we should support modifying array Likewise, I don't think we should support mutating |
Should we go so far as removing the setter from the types? https://github.com/numpy/numpy-stubs/blob/master/numpy-stubs/__init__.pyi#L300 |
See discussion in https://github.com/numpy/numpy-stubs/issues/7. Though this is valid NumPy, users should be using `ndarray.view` instead of setting the dtype, and setting the dtype prevents sensibly making `ndarray` generic over dtype because of situations like this: ``` x = np.ones((2,), dtype=np.int64) # type is ndarray[np.int64] x.dtype = np.bool_ # What is the type now? ``` If someone really wants to do this, they will now have add an ignore, which should make it clear that type safety is going out the window.
PR banning the setter: numpy/numpy-stubs#47 |
See discussion in https://github.com/numpy/numpy-stubs/issues/7. Though this is valid NumPy, users should be using `ndarray.view` instead of setting the dtype, and setting the dtype prevents sensibly making `ndarray` generic over dtype because of situations like this: ``` x = np.ones((2,), dtype=np.int64) # type is ndarray[np.int64] x.dtype = np.bool_ # What is the type now? ``` If someone really wants to do this, they will now have add an ignore, which should make it clear that type safety is going out the window.
Updating this issue with my current plan to support dtypes; see also the discussion with @seberg in numpy/numpy-stubs#48.
|
The PR for introducing dtype support is up: #17719. |
Sanity check, should something like |
Per #7370 (comment), we could specify dtype as part of ndarray types (including type inference) by using NumPy's scalar types, e.g.,
np.ndarray[Any, np.float64]
ornp.ndarray[np.float64, Any]
(whereAny
indicates the shape).Is this a good way to indicate dtypes? How would we handle dtypes that don't have a well specified scalar type? For example:
datetime64
andtimedelta64
do not have precision as part of the typenp.void
is used for all arbitrary structured dtypes, but doesn't indicate the field names or subtypes (side note:np.struct
would be a much better name)One simple answer is to not worry about more detailed type information for now, and worry about more precise specification for scalar types later, when support in the typing module becomes available (e.g., for integer types or custom struct-like data structures like
TypedDict
).The text was updated successfully, but these errors were encountered: