BUG: job that returns a numpy array fails

[FabiPi3]

Consider this example:

import numpy as np
from jobflow import job, run_locally

@job
def return_numpy():
    return np.array([[1, 2], [3, 4]])

run_locally(return_numpy(), ensure_success=True)

While I expect this to work, the output can literally be anything, it actually fails. Error message:

Traceback (most recent call last):
  File "/Users/fabianpeschel/miniconda3/envs/exwoflow313/lib/python3.13/site-packages/jobflow/managers/local.py", line 117, in _run_job
    response = job.run(store=store)
  File "/Users/fabianpeschel/miniconda3/envs/exwoflow313/lib/python3.13/site-packages/jobflow/core/job.py", line 630, in run
    response = Response.from_job_returns(
        response, self.output_schema, job_dir=job_dir
    )
  File "/Users/fabianpeschel/miniconda3/envs/exwoflow313/lib/python3.13/site-packages/jobflow/core/job.py", line 1315, in from_job_returns
    if job_returns and isinstance(job_returns, (list, tuple)):
       ^^^^^^^^^^^
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

The bug appeared when switching to the newest version 0.3.1. I think the issue was introduced in here: #848
The test if job_returns doesn't work for arrays. One would need a separate handling for this.

Probably @gpetretto and @utf can have a look.

[davidwaroquiers]

Thanks @FabiPi3

Truthiness in python at its best ... Sometimes I wonder why this is a python feature.

It is indeed a bug (I think, @gpetretto can you confirm). I think the fix is easy, is to replace:

if job_returns and isinstance(job_returns, (list, tuple)):

by

if job_returns is not None and isinstance(job_returns, (list, tuple)):

@gpetretto What do you think ?

[davidwaroquiers]

Checking a bit more I think it might need to be something like:

if isinstance(job_returns, (list, tuple)) and len(job_returns) > 0:

In my previous suggestion, an empty list again gives a replace because all([]) is True..

[gpetretto]

I think this last option makes sense. I proposed to fix this in #856, so that it also takes into account the dict case.