[typing] add internal DTypeLike specializations #18194
Conversation
jakevdp
force-pushed
the
dtypelike
branch
4 times, most recently
from
cf6d817 to
6d87bfd
Compare
| # Unlike np.typing.DTypeLike, we exclude None, and instead require | ||
| # explicit annotations when None is acceptable. | ||
| # TODO(jakevdp): consider whether to add ExtendedDtype to the union. | ||
| DTypeLike = Union[ |
There was a problem hiding this comment.
Why is it a bad idea to define DTypeLike as a union of the specialized DTypeLike* aliases below?
There was a problem hiding this comment.
DTypeLike is used in public APIs, so if we change it there's a good chance the perturbation will break the builds of downstream packages. Plus the simplicity here is nice (even if there are invalid strings that it lets through).
|
I don't think we can merge this: the issue is that these specializations reject valid code if the value of the string input is unknown statically to the type checker. The semantics I want are to allow any generic string in general, BUT if the string value is known statically, it must match one of the known values. As far as I understand, Python's type annotation syntax cannot express that, so accepting any |
No description provided.