Florian Jetter

TLDR The current system assumes strongly, in many places, that a key uniquely identifies a task, not just the output. Reusing a key for a different task violates this and...

@crusaderky I can't truly follow your example [here](https://github.com/dask/dask/issues/9888#issuecomment-1408605395) but it is a different issue. I'm talking about a guarantee that the task has to be uniquely identifiable by the key...

> The reason is the simple fact that there is no (formal/robust) mechanism to "replay" the construction of a graph after the names/properties for a subset of its tasks has...

> > xref https://github.com/dask/dask/issues/8635. Like @rjzamora said: > > if you change the name of the layer, you also have to change the names referenced in the dependent layers. That's...

Thanks, that clears things up for me.

Thanks for your report. This is actually intended behavior and the special case of `nout=1` is even mentioned explicitly in the [documentation](https://docs.dask.org/en/stable/delayed-api.html#dask.delayed.delayed). If anything, we should raise in this case...

Possibly but we'd likely need to relax the check on the object. While a tuple is surely the desired output I expect there are users that are relying on this...

xref https://github.com/dask/dask/pull/10808

The proposed algorithm very likely would also allow us to implement `duplicated`, see https://github.com/dask/dask/issues/1854 If #1854 is solved, the drop would merely be an additional filter step.

> In the end, we switched to the distributed.LocalCluster which does release the processed partitions, even with the original graph. I recommend using LocalCluster for everything. It comes with many...