Open nicolasmueller opened 6 months ago
I think I might have written the test_change_bound_argument
test case without properly thinking about what the actual intended behaviour should be. I agree that modifying the arguments after binding them to a task shouldn't have an influence on the task outcome. While I initially had some concerns about the use of deepcopy, I think that it shouldn't lead to any issues, because tasks only support a limited set of input types.
@NicholasHoernleQC what's your opinion on this :) , i.e. should we copy and freeze task inputs at declare time?
I think we can go for the "safe" solution to deep_copy the inputs even though I recommend noone to write code where this matters. Performance slowdown should be negligible compared with what computations we expect to be performed in pipedag. Thus modifying the test is fine.
Currently task inputs may me modified after the task has been declared. This leads to the unintuitive situation that a task may receive different arguments at runtime than at declaration time. In particular constructions like
crash at flow runtime, because
double_a
at runtime depends on the last version oftables
which contains"dfA2"
already.Note that a fix for this breaks
test_change_bound_argument
.Is the current behavior intended?
Checklist
docs/source/changelog.md
entry