parametrized_dag_factory behaviour

[sylvainbonnot]

The behaviour of parametrized_dag_factory
is not too intuitive: one gets the following

@code_to_dag
def testdag():
    a = criss(x,y)
    b = cross(aa, bb)
    c = apple(a, b)

dag_factory = parametrized_dag_factory(testdag, 'a')
Sig(dag_factory(x=1,y=2))
# <Sig (b)>

but the expected might be <Sig (aa, bb)> ?

Also, when a function in the dag has no params, the parametrized_dag is not consistent with the above:

@code_to_dag
def testdag():
    a = criss()
    b = cross(aa, bb)
    c = apple(a, b)

dag_factory = parametrized_dag_factory(testdag, 'a')
Sig(dag_factory())
# <Sig (a, b)>  # to be consistent with the above, it should be Sig (b)

[thorwhalen]

Great observations and I agree on both:

• Indeed, my intent was that the first be Sig (aa, bb)
• Consistency is crucial. Without any clear argument or narrative supporting it, I'd put forth an hypothetical rule of thumb: (Behavioral) consistency trumps intuitiveness.

This is a first draft of the function, so maybe it's an actual bug that we can resolve. Unfortunately, there's a chance it may be a bit more involved than that.

Maybe it's a bug else where (ancestors? partial?).

Or maybe, and that would suck, it's one of those "can't satisfy all expectations" kind of problem. Example; the non-obvious (C3 linearization](https://blog.pilosus.org/posts/2019/05/02/python-mro/) solution to getting a method-resolution-order (MRO) that would preserve the order of classes as defined by the programmer, while also preserving the monotonicity of the inheritance graph.

Either way, I'm moving this to a discussion so we can figure out what behavior we actually want (we now have two examples of what we do not want.