TYP: Make datetime64 a generic type at runtime
#29631
Conversation
jorenham
force-pushed
the
typing/runtime-generic-datetime64
branch
from
290b83a to
ef9edae
Compare
| @@ -4564,6 +4568,7 @@ initialize_numeric_types(void) | |||
|
|
|||
| /**end repeat**/ | |||
|
|
|||
| PyDatetimeArrType_Type.tp_methods = datetimetype_methods; | |||
There was a problem hiding this comment.
Nice.
I don't know much about the __class_getitem__ protocol implementation, don't the other dtypes need them as well? Why are datetime64 and bool special?
There was a problem hiding this comment.
In case of np.bool it can be useful to be able to distinguish between np.True_: np.bool[Literal[True]] and np.False_: np.bool[Literal[False]] like that.
For np.datetime64 the generic type parameter tells what .item() will return. So np.datetime64[None] is the type of NaT, np.datetime64[int] have units below ms, and likewise there are np.datetime64[datetime.datetime] and np.datetime64[datetime.date].
For the other conrete scalar types, at least the numerical ones, there are no such usecases at the moment.
So in short: If you write np.int8[Any] you'll see a squiggly. If you write np.bool[Any] or np.datetime64[Any], you don't.
|
Thanks @jorenham |
In the stubs,
datetime64is a generic type with an optional type parameter. But due to the lack of__class_getitem__, something likenp.datetime64[int]would fail at runtime, even though it's valid in static typing land.This changes
datetime64so that it's can also be used as generic type at runtime by adding a__class_getitem__method that returns atypes.GenericAliasType(yea, the naming is horrible...).Before:
After:
(I'm getting pretty good at pretending to know C, eh?)
related to #29370