Skip to content

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

Merged
merged 11 commits into from
Sep 7, 2020

Conversation

BvB93
Copy link
Member

@BvB93 BvB93 commented Sep 1, 2020

This pull request fixes a number of things related to the annotations of various np.generic subclasses:

  • 3434da8 & e171b2b: Adds previously missing types to the constructors.
  • 3434da8: Adds missing builtin baseclasses to the likes of np.str_ and np.float128.
  • 8f2c26d: Make np.datetime64 a subclass of np.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 in np._ArrayOrScalarCommon have been annotated then the remaining issues will likelly resolve themselves.
  • d6b0c70: Per the discussion in ENH: Make np.complexfloating generic w.r.t. np.floating #17172 this limits the np.generic.real and .imag properties to numeric np.generic subclasses.
    On the side of caution I've also included np.object_ and np.void, as the latter two may or may not contain numeric types (any thoughts on this?).

class signedinteger(integer): ... # type: ignore

class int8(signedinteger):
def __init__(self, __value: SupportsInt = ...) -> None: ...
def __init__(
self, __value: Union[SupportsInt, SupportsIndex, str, bytes] = ...
Copy link
Member Author

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

@BvB93
Copy link
Member Author

BvB93 commented Sep 1, 2020

This is odd, np.complex64 has issues accepting objects with the __index__ protocol when running the Windows Python37-64bit-full tests.
I think this might be an actual bug?

Examples

Failed test: https://dev.azure.com/numpy/numpy/_build/results?buildId=12396&view=logs&j=41da7a62-01d8-5a8a-1897-893bcc993eb5&t=6e2ca7fa-7d8b-55ee-d2ce-056d635fc0b4&l=249

Slimmed 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

@eric-wieser
Copy link
Member

That looks like it's probably a bug, although I'm not quite clear enough on the semantics of __index__ to be sure it wasn't deliberate. It's definitely inconsistent with python though.

@BvB93
Copy link
Member Author

BvB93 commented Sep 1, 2020

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 __index__ protocol in (builtin) scalar constructors was only added in python 3.8.
I suspect the same holds for np.number.

@eric-wieser
Copy link
Member

Sounds like we should change numpy to be consistent then, perhaps conditional on python >=3.8

@BvB93
Copy link
Member Author

BvB93 commented Sep 1, 2020

Alright, c9bb44b should fix the python < 3.8 __index__ issue.

@charris charris merged commit 9c9df9c into numpy:master Sep 7, 2020
@charris
Copy link
Member

charris commented Sep 7, 2020

Thanks @BvB93 .

@BvB93 BvB93 deleted the generic branch September 8, 2020 11:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants