-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
MAINT: Fix various issues with the np.generic
annotations
#17214
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
Conversation
numpy/__init__.pyi
Outdated
class signedinteger(integer): ... # type: ignore | ||
|
||
class int8(signedinteger): | ||
def __init__(self, __value: SupportsInt = ...) -> None: ... | ||
def __init__( | ||
self, __value: Union[SupportsInt, SupportsIndex, str, bytes] = ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
np.numbers
apparently also support objects with SupportsIndex
protocol, just as their builtin counterparts:
https://github.com/python/typeshed/blob/ccfc1850e9b61bb891e45a679a55d7d654992b7c/stdlib/2and3/builtins.pyi#L182
This is odd, ExamplesSlimmed down example: >>> import numpy as np
>>> class D:
... def __index__(self) -> int:
... return 0
>>> np.complex64(D())
Traceback (most recent call last):
...
TypeError: must be real number, not D |
That looks like it's probably a bug, although I'm not quite clear enough on the semantics of |
Oh hang, I've found the issue: https://docs.python.org/3/whatsnew/3.8.html#other-language-changes (third bullet point) It seems support for the |
Sounds like we should change numpy to be consistent then, perhaps conditional on python >=3.8 |
Alright, c9bb44b should fix the python < 3.8 |
Thanks @BvB93 . |
This pull request fixes a number of things related to the annotations of various
np.generic
subclasses:np.str_
andnp.float128
.np.datetime64
a subclass ofnp.generic
(again), thus partially reverting Added typing information for datetime64, timedelta64 numpy-stubs#31 (comment).The issues encountered in the linked comment have been partially addressed by explicitly defining a few
__r<op>__
methods. Once the, currently untyped, magic methods innp._ArrayOrScalarCommon
have been annotated then the remaining issues will likelly resolve themselves.np.complexfloating
generic w.r.t.np.floating
#17172 this limits thenp.generic.real
and.imag
properties to numericnp.generic
subclasses.On the side of caution I've also included
np.object_
andnp.void
, as the latter two may or may not contain numeric types (any thoughts on this?).