feat(udf): support both ibis and original types

[NickCrews]

Is your feature request related to a problem?

consider

import ibis

@ibis.udf.scalar.python
def add_one(x: int) -> int:
    return x + 1

add_one(ibis.literal(3))  # ibis.expr.types.numeric.IntegerScalar
add_one(3) # ibis.expr.types.numeric.IntegerScalar

Can we make it so that add_one(3) returns a vanilla python int? This would really help make my UDFs polymorphic out of the box.

I have this sense of deja vu I asked about this before, but I just searched the issues and didn't find anything. Apologize if so!

What is the motivation behind your request?

No response

Describe the solution you'd like

Currently I have this workaround:

def flexiblize_udfs(udf):
    def inner(x):
        if isinstance(x, (ibis.Value, ibis.Deferred)):
            return udf(x)
        else:
            return udf.__wrapped__(x)

    return inner

flexiblize_udfs(add_one)(3)  # vanilla python 4 

I think the logic I have above should suffice? The semantics of the UDF decorator is now "add udf support to the given function" instead of "turn the supplied function into a udf".

What version of ibis are you running?

main

What backend(s) are you using, if any?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[cpcloud]

I think this opens a large can of worms where we now have to think about local execution even in the case of a UDF running on a remote backend.

Hypothetically, what if some expression is evaluated locally in Python 3.10 and then remotely in Python 3.12 and there are dependencies in the mix, which might differ, we have to at least be forced to think about that and probably document it, whereas we can simply not do it and we don't have to worry about the environment disparity.

[NickCrews]

I didn't think about that, I only was thinking about my duckdb experience. That makes sense, I agree that potential inconsistency seems dangerous. My wrapper is a pretty easy workaround. Thank you!