Additional lifted operators

[Andrew-S-Rosen]

Is your feature request related to a problem? Please describe.

Following up #2904, we should consider adding additional "lifted" operators based on the special method names list.

Describe the solution you'd like

More lifted operators!

Describe alternatives you've considered

No more lifted operators, but that would be sad 😢

Additional context

We need to decide which methods to implement and which to not implement. Actually implementing it and adding tests is trivial. I am happy to do that.

The main category to look at, in my opinion, is the list of numeric types. Which of these should we be implementing? There are a lot, and not all of them are necessarily worthwhile to include.

My proposal at the moment is to include the following:

object.__add__(self, other)
object.__sub__(self, other)
object.__mul__(self, other)
object.__truediv__(self, other)
object.__pow__(self, other[, modulo])

with the following potentially also being worthwhile:

object.__floordiv__(self, other)
object.__mod__(self, other)
object.__divmod__(self, other)
object.__matmul__(self, other)

But at the same time, this then raises questions to the user: how do they know what will and won't work? Maybe we just add documentation somewhere with a table?

[Andrew-S-Rosen]

Side-note: I wonder if there is some way to support the following behavior using a similar approach:

from parsl import python_app

@python_app
def test(a, b):
    c = a + 1
    d = b + 1
    return c, d

c_future, d_future = test(1, 2)

I wonder if users might expect this to be possible...

[benclifford]

I don't think this case is distinguishable from returning a tuple (c,d) that the user intends to be contained in a single future.

[Andrew-S-Rosen]

from parsl import python_app

@python_app
def test(a, b):
    c = a + 1
    d = b + 1
    return (c, d)

future = test(1, 2)

The above always works, of course. But in "normal Python", one might expect to be able to do c, d = test(1, 2) instead, which won't work (ValueError: too many values to unpack (expected 2)). Not a big deal since it really is a single future being returned, but I brought it up anyway.

Unless you meant something else?

[benclifford]

I think it would need the appfuture to be iterable (so as to generate Futures for each possible future element, to them be assigned to the receiving c_future, d_future variables) but I don't think the app future could be iterable because it doesn't know enough about the iterable-ness of the underlying value contained in the future: most specifically, I think, it doesn't know the number of elements to make entry-future for. (this is like for AppFutures-of-dicts, you can't ask for the list of available names using keys() - you can only ask for a name and wait until the future to discover if it exists or not)

[Andrew-S-Rosen]

Ah, that is a good point. You're right. The length isn't known a priori.

[Unique-Usman]

Hello @benclifford , can I be assigned this task. It seems interesting, kindly provide any resources that can be of help in resolving this. Thank you.

[mirembe-mariam]

hello @benclifford , can i work on this issue?

[Unique-Usman]

I think you can go ahead @mirembe-mariam since I got occupied with some other stuffs.