Test not failing consistently

[EmilyBourne]

Describe the bug

We can see here that the test test_multi_return_array_scalar_op is (occasionally) failing when converting to Python. In the link this occurs on Python 3.7 however looking at the commit history we can see that this does not occur systematically. As described below, the bug is expected. It is therefore concerning that the test does not fail every time. We should find out why this is the case before fixing the bug

To Reproduce

Provide code to reproduce the behavior:

        @types('int8')
        @types('int16')
        @types('int32')
        @types('int64')
        @types('int')
        @types('float32')
        @types('float64')
        @types('float')
        @types('complex64')
        @types('complex128')
        def return_multi_array_scalar_op(a):
            from numpy import ones, int8, int16, int32, int64, float32, float64, complex64, complex128 #pylint: disable=unused-import
            x = ones(5, dtype=type(a))
            y = ones(5, dtype=type(a))
            return x * a, y * a

Error details

Provide the generated code:

from pyccel.decorators import types

@types('int8')
@types('int16')
@types('int32')
@types('int64')
@types('int')
@types('float32')
@types('float64')
@types('float')
@types('complex64')
@types('complex128')
def return_multi_array_scalar_op(a):
    from numpy import float64, int8, int64, int32, ones, float32, complex64, complex128, int16
    x = ones((5), dtype=int8)
    y = ones((5), dtype=int8)
    return x * a,y * a

We see that the dtype is now set to int8 instead of type(a). This is due to the poor handling of interfaces in the python translation as discussed in #802 and #1334. However the problem is avoidable here by propagating the PythonType instance to the printer instead of replacing it with the type in the semantic stage.

Expected behavior

Either the PythonType instance should be propagated to the printer instead of replacing it with the type in the semantic stage. Or if code duplication reduction is preferred then the test should be skipped with an appropriate reason.

Language

Python

Acceptance criteria

• Find why the error was not reported consistently
• Fix the bug

[EmilyBourne]

It passes due to the multiplication x * a, y * a. x and y have the same type as the first type instruction (int8) so x * a promotes the result to the same type as a. This does not explain why the test sometimes fails with the wrong type.

The generated code is:

from pyccel.decorators import types

@types('int8')
@types('int16')
@types('int32')
@types('int64')
@types('int')
@types('float32')
@types('float64')
@types('float')
@types('complex64')
@types('complex128')
def return_multi_array_scalar_op(a : int):
    from numpy import ones, int32, int16, int8, float64, complex128, complex64, int64, float32
    x = ones((5), dtype=int8)
    y = ones((5), dtype=int8)
    return x * a,y * a

[EmilyBourne]

Second example : https://github.com/pyccel/pyccel/actions/runs/5142867750/jobs/9257153359