Support for library specific annotations #464
Conversation
magnatelee
added
the
category:new-feature
legate/core/context.py
Outdated
| return len(self._entries) == 0 | ||
|
|
||
| def __getitem__(self, key: str) -> Optional[str]: | ||
| return self._entries[key] if key in self._entries else None |
There was a problem hiding this comment.
also an option:
| return self._entries[key] if key in self._entries else None | |
| return self._entries.get(key, None) |
There was a problem hiding this comment.
__get_item__ and __set_item__ are removed
legate/core/context.py
Outdated
| ) | ||
|
|
||
| def __repr__(self) -> str: | ||
| return str(self) |
There was a problem hiding this comment.
Could move __str__ implementation here, and then get __str__ for free
legate/core/context.py
Outdated
|
|
||
| def __enter__(self) -> None: | ||
| for key, value in self._pairs.items(): | ||
| self._annotation[key] = value |
There was a problem hiding this comment.
I think self._annotation.update(**pairs) would also work
legate/core/context.py
Outdated
| return str(self) | ||
|
|
||
|
|
||
| PROVENANCE_KEY = "Provenance" |
There was a problem hiding this comment.
I usually tack on some dunders for good measure if I am reserving a "special" key name that I don't want to collide with anything a user might supply
There was a problem hiding this comment.
Though as long as there is already a class LibraryAnnotations couldn't the provenance be stored separately instead of in the same dict?
There was a problem hiding this comment.
took the suggestion that the provenance can be separate
legate/core/context.py
Outdated
| return "|".join( | ||
| pairs | ||
| if self._provenance is None | ||
| else chain(pairs, (f"Provenance,{self._provenance}",)) | ||
| ) |
There was a problem hiding this comment.
maybe a little simpler, and avoids the itertools import:
| return "|".join( | |
| pairs | |
| if self._provenance is None | |
| else chain(pairs, (f"Provenance,{self._provenance}",)) | |
| ) | |
| if self._provenance is not None: | |
| pairs += (f"Provenance,{self._provenance}",) | |
| return "|".join(pairs) |
There was a problem hiding this comment.
ok I didn't know you could add a tuple to a generator, but wouldn't that materialize the generator into some sequence?
There was a problem hiding this comment.
looks like I can't even do it
TypeError: unsupported operand type(s) for +=: 'generator' and 'tuple'
There was a problem hiding this comment.
I mean, I'm fine with materializing the generator into a list, I guess I was trying to be too clever...
There was a problem hiding this comment.
oh right, you'd have to call tuple on it first, either way seems fine (I'm assuming it's a pretty small list of things)
This PR adds an
Annotationclass with which client libraries can attach client specific annotations other than the provenance to operations. Here's an example of how an operator name added as an annotation in cuNumeric gets rendered: