I think we can drop handling of key=str in set, at least in my case it will not happen, but it does leave a possibility for future unintended problems like this.

I think we can drop handling of key=str in set, at least in my case it will not happen, but it does leave a possibility for future unintended problems like this.

dropping key=str would cause a failure for tokenize({1, (2, 3)}).
Ultimately I would much rather work on the assumption that str() is cheap for all objects.

Sure - I think that's fine and reasonable for set. It may still be useful to stick in the documentation a louder warning/callout/suggestion that __dask_tokenize__ is very much the preferred option. Sorry - confusing the two underlying issues / causes. I blame 9 hours of jetlag.

Unit Test Results

See test report for an extended history of previous test failures. This is useful for diagnosing flaky tests.

     15 files  ± 0       15 suites  ±0   3h 21m 27s ⏱️ + 5m 9s
 13 024 tests + 3   12 094 ✅ + 3     930 💤 ±0  0 ❌ ±0 
161 047 runs  +45  144 556 ✅ +44  16 491 💤 +1  0 ❌ ±0 

Results for commit bbd0c87. ± Comparison against base commit 07099e5.

♻️ This comment has been updated with latest results.

thx @crusaderky