Description
This effectively comes down to porting over the optype.numpy.Any*DType
type aliases (docs), and stripping away the compatibility stuff for older numpy version.
naming scheme
The naming scheme of these dtype-likes in optype.numpy
is admittedly rather awkward, so a that should also be changed (but not in optype
; that'd break scipy-stubs
).
Some options for a new naming scheme are (taking dtype[int8]
and dtype[str_]
as example)
As{}DType
(pros:np.dtypes
compat, cons: no abbrev & meh readability)AsInt8DType
AsStrDType
AsDType{}
(pros: autocompletion & could abbr, cons: yoda &np.dtypes
incompat)AsDTypeInt8
/AsDType_int8
/AsDType_i1
AsDTypeStr
/AsDType_str
/AsDType_U
DTypeLike{}
(pros: autocompletion & could abbr &np._typing
compat, cons: long & yoda &np.dtypes
incompat)DTypeLikeInt8
/DTypeLike_int8
/DTypeLike_i1
DTypeLikeStr
/DTypeLike_str
/DTypeLike_U
{}DTypeLike
(pros: readability &np.dtypes
compat, cons: long & no abbrev)Int8DTypeLike
StrDTypeLike
datetime64
and timedelta64
Analogous to the three or four distinct generic variants of the scalar types (unit-based), these dtypes could be further split up into "sub-dtype-likes" for:
datetime64[None]
/datetime64[int]
/datetime64[dt.datetime]
/datetime64[dt.date]
timedelta64[None]
/timedelta64[int]
/timedelta64[dt.timedelta]
void
Note that for void
things become rather complex, because it includes all possible structured dtypes, but can also be bytes-like. So perhaps it makes sense to split it up into two non-overlapping dtype-like types:
- structured, i.e. those with
.ndim > 0
: acceptslist[tuple[...]] | ct.Struct | ct.Enum
- raw, i.e. those with
.ndim == 0
: acceptstype[void] | L["void", "V", "\x14", ...] | ...
incompleteness
Not all dtypes can be completely described, because they accept an infinite amount of possible strings. This is the case for
datetime64
andtimedelta64
(i.e.e.g."M8[42as]"
)flexible
, i.e.bytes_
,str_
, andvoid
(i.e.e.g."S1337"
)
So in these cases, a "catch-all" overload for the remaining str
should be used.