Closed
Description
Some issues with type annotations that were brought up by @BvB93 at numpy/numpy#18585
- For
asarray
, it isn't clear how to defineNestedSequence
(typing
annotations don't support recursive types). -
asarray
needs to also includearray
as a valid type forobj
(array
should not be considred a subtype ofNestedSequence
) - The pipe operator for types isn't valid yet (https://www.python.org/dev/peps/pep-0604/) (it's used in the
NestedSequence
type inasarray
) - For
stack
andconcat
, the type forarrays
should beTuple[array, ...]
instead ofTuple[array]
- For
stack
andconcat
(and possibly others),Tuple
is too restrictive vs.Sequence
. -
unique
can be implemented as an@overload
(see ENH: Implementation of the NEP 47 (adopting the array API standard) numpy/numpy#18585 (comment)). I don't know if this needs to be changed in the spec. - The return type for
finfo
asfinfo
doesn't make sense iffinfo
is a function (see ENH: Implementation of the NEP 47 (adopting the array API standard) numpy/numpy#18585 (comment)). -
__getitem__
and__setitem__
should include theellipsis
type (ENH: Implementation of the NEP 47 (adopting the array API standard) numpy/numpy#18585 (comment)) -
(update:__len__
should returnint
__len__
is slated for removal from the spec; see Specify shape behavior #289) - The return type for
shape
is currentlyUnion[ Tuple[ int, …], <shape> ]
, which needs to be addressed (there is a TODO in the spec for this). (update: see Specify shape behavior #289) -
Some of the other types for properties also use<...>
types. We should make all the type annotations be valid Python/mypy that can be used in the annotations in the signature. -
Should the array object subclass fromtyping.Protocol
(ENH: Implementation of the NEP 47 (adopting the array API standard) numpy/numpy#18585 (comment))? (I don't know if this is relevant for the spec). - The dunder methods (
__add__
, and so on) should includeint
,float
, (andbool
as appropriate) as allowed types forother
.