Conversation
Unit Test ResultsSee test report for an extended history of previous test failures. This is useful for diagnosing flaky tests. 9 files ± 0 9 suites ±0 3h 10m 14s ⏱️ +28s Results for commit 450a42f. ± Comparison against base commit 1a306ba. ♻️ This comment has been updated with latest results. |
jacobtomlinson
left a comment
There was a problem hiding this comment.
It looks like the broad exception was added in #3230 to enable mixing of dataframe and arrays for aligned element-wise operations.
You mention removing it because it's misleading, but I assume it's to handle unexpected cases when comparing the two kinds of objects. Given that it's looking for unexpected mismatches there are probably no good tests for this situation so I don't feel confident in merging this without exploring this further.
|
Hi @jacobtomlinson, thanks for the review. If it's better I can add back the try-except, but ideally it would nice to avoid catching all exceptions. That said, given it's not clear how to test I'm not sure how to proceed on that front. |
|
I think the try/except is there to handle these unknown cases. If you can resolve your bug without removing it then I think that would be best. |
dask.array.choose()fails when the choice is trivial #11980pre-commit run --all-filesThis PR does a simple fix for the following bug:
The output arises from
dask/dask/array/core.py
Lines 4974 to 4977 in 1a306ba
which in turn comes from
dask/dask/array/core.py
Lines 479 to 486 in 1a306ba
which causes a failure since it later runs
I have removed the try-except which gave the
NotImplementedoutput since I think it's misleading, and I've added the simplest fix I could think of, namely to usezeros_likeinstead ofones_like. This ends up callingnp.choose(np.array([0]), np.array([0])without any issues.