Previously `dask.multiprocessing.get` would accidentally forward `HighLevelGraph` graphs through the dask optimization/scheduling routines, resulting in odd errors. One way to trigger this was to have a non-indexable object in a task. This is just a smoketest to ensure that things wo
()
| 156 | |
| 157 | |
| 158 | def test_works_with_highlevel_graph(): |
| 159 | """Previously `dask.multiprocessing.get` would accidentally forward |
| 160 | `HighLevelGraph` graphs through the dask optimization/scheduling routines, |
| 161 | resulting in odd errors. One way to trigger this was to have a |
| 162 | non-indexable object in a task. This is just a smoketest to ensure that |
| 163 | things work properly even if `HighLevelGraph` objects get passed to |
| 164 | `dask.multiprocessing.get`. See https://github.com/dask/dask/issues/7190. |
| 165 | """ |
| 166 | |
| 167 | class NoIndex: |
| 168 | def __init__(self, x): |
| 169 | self.x = x |
| 170 | |
| 171 | def __getitem__(self, key): |
| 172 | raise Exception("Oh no!") |
| 173 | |
| 174 | x = delayed(lambda x: x)(NoIndex(1)) |
| 175 | (res,) = get(x.dask, x.__dask_keys__()) |
| 176 | assert isinstance(res, NoIndex) |
| 177 | assert res.x == 1 |
| 178 | |
| 179 | |
| 180 | @pytest.mark.parametrize("random", ["numpy", "random"]) |
nothing calls this directly
no test coverage detected
searching dependent graphs…