Add notes on unexpected inputs and mixing array types to Scope section #58
Conversation
| @@ -126,6 +133,13 @@ extensions are dealt with_): | |||
| library switches from one array type to another, some testing and possibly | |||
| code adjustment for performance or other reasons may be needed._ | |||
|
|
|||
| - Making it possible to mix multiple array libraries in function calls. | |||
There was a problem hiding this comment.
What about native Python types (int, float, bool, list)? I've been trying to avoid using them anywhere in the test suite except for full, but perhaps that is too restrictive. OTOH, float((), 1.0, dtype=float64) is more explicit about the dtype than just 1.0.
There was a problem hiding this comment.
Good question. This was discussed in gh-14, with the decision that it shouldn't be allowed in functions calls, and that we'd need a special case for array + scalar (to be added to the dunder methods). I will need to double check if that's spelled out clearly enough.
There was a problem hiding this comment.
EDIT: "shouldn't be allowed" --> "shouldn't be required".
There was a problem hiding this comment.
I looked into this, the Python types clarification is needed. I believe it should go into the sections "Function and method signatures" and "Array object" rather than here. So I'll send a follow-up PR for that.
There was a problem hiding this comment.
- I've just tested with TensorFlow 2.3.0 and recent JAX and CuPy; it looks like all libs now support using scalars in function calls. This needs to be stated explicitly.
- The type promotion section says "Non-array ("scalar") operands are not permitted to participate in type promotion.", so that part is covered.
This question has come up multiple times already, so be explicit that we do not want to specify exception types or other behaviour resulting from unexpected usage scenarios.