can we just always do this?

Indeed, This was one of my previous comments. It could depend on the type of the result returned by the function. But since the result has to be embedded in an expression string passed to numexpr.evaluate() it's probably safer to use variable names instead of string representations.

Unless it has an interest for some very specific cases like some literals of base types.

ok if you can try that would be great

I've done some tests with numexpr.

For instance this works:

numexpr.evaluate("2 * a + b", {"a": np.array([0.0, 0.0]), "b": [1, 2]})

while this doesn't:

numexpr.evaluate("2 * a + [1, 2]", {"a": np.array([0.0, 0.0])})

So I guess the number of cases where it's a bad idea to use variables instead of literals is quite reduced.
It would basically work only for integer literals (doing it for floats would lead to truncation). Is it worth making such an exception knowing that it will work using variables anyway ?

no, try to make the change to just fix this (of course if you can additional tests would be great)

Sorry, I'm not sure to understand what additional changes you have in mind. As it is, the PR does the job.

As for the additional tests, while I agree that the proposed tests are more functional non regression tests than unit tests, I'm a bit short on the way to make proper unit tests. If you have suggestions, I would be happy to implement them.

no what i mean is that i would like to have your patch handle all of the cases and not special case (which i think it works).