Better layer name synthesis for non-HLGs#5888
Merged
mrocklin merged 2 commits intodask:masterfrom Feb 14, 2020
Merged
Conversation
When a dependent collection passed to HighLevelGraph.from_collections has a __dask_graph__ that is not a HighLevelGraph, the layer synthesised for it was being named with `id()`. This caused problems, because there are places in the code that assume that the layer name matches the key names inside the layer (see dask#5850), and dask.array.utils._check_dsk asserts that layer names are all tuples or strings, not integers. Address withby naming the layer `collection.__dask_layers__()[0]`, falling back to the old behaviour if `__dask_layers__` doesn't exist or returns an empty tuple. I'm not sure what the ideal behaviour is if `__dask_layers__()` returns more than one element. The built-in collections (array, dataframe, bag and delayed) all return a singleton; xarray's Dataset can return multiple values, but it also returns a HighLevelGraph from `__dask_graph__` so the issue doesn't arise. Closes dask#5850.
Contributor
Author
|
There is a test failure (at least when it was tested on my branch), but it also appears to be failing on master. |
mrocklin
reviewed
Feb 14, 2020
dask/highlevelgraph.py
Outdated
| else: | ||
| key = id(graph) | ||
| try: | ||
| key = collection.__dask_layers__()[0] |
Member
There was a problem hiding this comment.
Maybe this just to assert that we're not accidentally dropping any information here? If this situation does arise (other collections exist) at least we'll fail more loudly.
Suggested change
| key = collection.__dask_layers__()[0] | |
| [key] = collection.__dask_layers__() |
If a collection does not have a HighLevelGraph and we're using `__dask_layers__` to pick a name to use to convert to a HighLevelGraph, raise an error if there is not exactly one name in `__dask_layers__`, rather than just taking the first one.
Member
|
Thanks @bmerry ! Merging in. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
when a dependent collection passed to HighLevelGraph.from_collections
has a
__dask_graph__that is not a HighLevelGraph, the layer synthesisedfor it was being named with
id(). This caused problems, because thereare places in the code that assume that the layer name matches the key
names inside the layer (see #5850), and dask.array.utils._check_dsk
asserts that layer names are all tuples or strings, not integers.
Address withby naming the layer
collection.__dask_layers__()[0],falling back to the old behaviour if
__dask_layers__doesn't exist orreturns an empty tuple. I'm not sure what the ideal behaviour is if
__dask_layers__()returns more than one element. The built-incollections (array, dataframe, bag and delayed) all return a singleton;
xarray's Dataset can return multiple values, but it also returns a
HighLevelGraph from
__dask_graph__so the issue doesn't arise.Closes #5850.
black dask/flake8 dask