Hi Joren, As a person who doesn't use typing, some perhaps naive questions about your comments, but ones that express my worry that the current state of typing, which would seem a fast-moving and still relatively in-flux feature, starts to influence the convenience of code.
You mention: > # 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. To me this seems somewhat orthogonal to the NEP. If it is important for `ByteStringDType`, it is even more important for `StringDType`, which will be substantially more used, and presumably the solution would be the same for both (some franken-subclass of `bytes` or `str` and `np.generic`, just like `np.float64` (which subclasses both `float` and `np.generic`; its mro is `np.floating`, `np.inexact`, `np.number`, `np.generic`, `float`, `object`). > 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`. As a non-typer, this feels weird. It suggests `NDArray` is treated a bit like a list, but then what is the problem with `NDArray[str]`? Or why would one not write `NDArray[Any]`? Maybe more broadly, why treat it like a list? Not all dtypes will have associated scalars; e.g., the SFloatDescr that is one of numpy's test cases, does not have a scalar type at all (I'm building on that example for astropy, so it has real-world uses). Indeed, the concept of scalars associated with dtypes is inconsistent with the Array API. At some level, it would be rather lovely if we could get rid of them altogether... I guess to ask it differently, why can one not write it with the dtype, i.e., `NDArray[StringDType]` so that the most general form would be `NDArray[np.dtype]`? Now probably this has all been discussed to death already, but I guess the general question is whether rather than try to adjust fairly logical choices to typing, it is possible to expand what typing can do so that it can express those choices... > # 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. I'm a bit confused about this one. How is this different from, e.g., the concept of byte order, which is not captured by the typing either? Also, pandas has particular integer values to indicate missing. Isn't that similar? Can that be captured by typing? Again, apologies for what are probably naive questions... All the best, Marten _______________________________________________ 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]
