Class for DAG functions

[lars-reimann]

What would you like to enhance and why? Is it related to an issue/problem?

Refer to iza-institute-of-labor-economics/gettsim#538 for a problem description.

Describe the solution you'd like

A class DagFunction akin to the following:

class DagFunction:
    def __init__(f: Callable, dag_key: str):
      ...

Additional context

Discussion started here.

[janosg]

Thanks for creating the Issue.

Currently, dags works with the following kinds of user provided functions:

1. A list of callables as long as each callable has a __name__ attribute
2. A dictionary of callables. Then the dict key defines the output name and the __name__ attribute is not used.

Internally, we convert case 1 into case 2 at the very beginning because this makes the DAG construction very easy.

I don't fully understand where the new class would come in an what problem it solves.

Would this be a third option for providing functions to dags that is similar to 1, except that __name__ is replaced by dag_key and instead of calling the object we would have to call DagFunction.f.

Or should this be used internally and if so, what would be simplified by it? The things that are solved by the PolicyFunction in gettsim do not really apply to dags since we only use standard attributes like __name__ and __signature__ internally.

I had understood our last discussion as gettsim rolls its own PolicyFunction class to store some internal data but I didn't expect this would need a change in dags.

There would be two ways of achieving this:

1. After doing all the processing, gettsim passes a transformed version of PolicyFunction.f to dags
2. PolicyFunction implements a __call__ method

We can also discuss this in person (@hmgaudecker @lars-reimann).

[hmgaudecker]

I had understood our iza-institute-of-labor-economics/gettsim#534 as gettsim rolls its own PolicyFunction class to store some internal data but I didn't expect this would need a change in dags.

I am not sure "need" is the right word -- the question raised towards the very end of that discussion was simply whether dags might be the right place to provide the machinery to store metadata.

I think that would be my answer to:

I don't fully understand where the new class would come in an what problem it solves.

and maybe the naming in the example above might not reflect that idea. Hence, to get everybody on the same page,

We can also discuss this in person

would probably be good!

[janosg]

After our discussion, I think I can close this? If not, feel free to re-open.