Thanks for this Nathan! There are a couple of static typing problems with the current NEP that I think are important, especially considering the static typing is becoming more widespread and important (it helps LLMs, for example).
# missing scalar type I think it's important that we also introduce a companion scalar type for this, instead of using the `builtins.bytes` for this. Currently `StringDType` is simply type-unsafe, and it's impossible to express a `StringDType` array using the widely used `numpy.typing.NDArray`. For example, this leads to `f(x: npt.NDArray[np.generic])` rejecting every `StringDType` array, even though `npt.NDArray[np.generic]` is supposed to represent the "top type" of `ndarray`. Moreover, it's also type-unsafe, meaning that it violates Liskov's substitution principle and can therefore lead to runtime errors that type-checkers cannot detect, even if they have 100% complete and accurate typing information. The consequence of this is that if you want currently want to use `StringDType` in your typed codebase, then you're forced to use the intrinsically type-unsafe `Any`, which snowballs into codebase that more type-unsafe in general, which makes it a lot more difficult to *prevent* bugs using static typing. So let's not repeat the mistakes of the past, and do it right from the start, i.e. by also adding a dedicated `BytesDType` scalar type that inherits from (at least) `numpy.generic`. # na_object As you probably already know, this feature of `StringDType` is problematic for static typing, because there is no good way to express this functionality in the stubs. And although I understand that it would be strange if the direct dual to `StringDType` wouldn't have the same `na_object` functionality, I'd rather we not repeat the mistakes of the past, taking the resulting inconsistency for granted. --- Joren _______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
