feat: astype: accept a kind of data type
#848
Conversation
rgommers
added
the
API change
There was a problem hiding this comment.
Thanks for getting the ball rolling on this @lucascolley! Some comments inline.
| For ``dtype_or_kind`` a data type, an array having the specified data type. | ||
| For ``dtype_or_kind`` a kind of data type: | ||
| - If ``x.dtype`` is already of that kind, the data type is maintained. | ||
| - Otherwise, an attempt is made to convert to the specified kind, according to the type promotion rules (see :ref:`type-promotion`). |
There was a problem hiding this comment.
Why "an attempt"? That seems ambiguous. We have to be clear about what must work. Which I think is:
- float to complex
- unsigned to signed integer
Anything else doesn't I think? There's no point allowing 'bool' I think, since there is only one boolean dtype so dtype=xp.bool will be cleaner.
For 'signed integer' and 'real floating-point'` there are also no promotion rules to follow, so they can be left out - or do you see a use case?
There was a problem hiding this comment.
I've reduced this down to just 'complex floating' (use-case: mixed float/complex to complex) and 'signed integer' (use-case: mixed signed/unsigned to signed).
I think "an attempt" would still be accurate for an implementation of this? xp.astype(some_int8_array, 'complex floating') would attempt a conversion, whose success will depend on the implementation-specific type promotion rules, right?
Unless you think that this function should always error when the type promotion is not defined by the standard?
There was a problem hiding this comment.
I think "an attempt" would still be accurate for an implementation of this?
I think you have the right idea in mind here, it's just a "language we use to specify things" thing. We specify which behavior has to be supported - 'complex floating' has type promotion rules defined in the standard, so it's expected to always work for a compliant implementation. Then, if we expect other input types to raise, then we specify that by "must raise ..." or "input type must be ...". In this case there's no reason to do that (implementors are free to suppport more types, it's just not standardized), so we then say "input type should be ...".
Your "attempt to ..." seems to be the same as "should be ...", it's just language we want to write in a uniform way.
There was a problem hiding this comment.
how about the wording now?
#841 (comment) @rgommers