Concisely describe the proposed feature
Kernels currently take dataclasses that match exactly the annotated type, but this misses out on the potential of elegant composition of dataclasses.
In particular, we find that in our codebase a pattern arises where we have a large dataclass, but with only a subset of the parameters being valid for use in quadrants kernels. Take the following example:
@dataclass
class QdDomain:
x: qdt.NDArray[qd.i32, qdt.Dim1]
@dataclass
class Domain(QdDomain):
y: str
@qd.kernel
def mykernel(domain: QdDomain) -> None: ...
domain = Domain(x=qd.ndarray(qd.i32, (100,)), y="Hi, there!")
mykernel(domain)Here, we try and separate out the kernel-relevant parameters from the parameters that cannot be used in the kernel. An easy way of doing this would be nested composition. So: Domain contains an attribute qd_safe: QdDomain. However, I find this slightly inelegant to require consumers to write domain.qd_safe.x when quadrants-safety is likely irrelevant to their task. The inheritance composition would be much nicer.
Furthermore, if we want quadrants to be type-checkable, there seems to be no way to annotate that kernels are invariant on their dataclass arguments. Python will always accept the above as valid. This is another reason we might want to make this meaningful.
Describe the solution you'd like (if any)
I believe an internal fix is very easy. In fact, it seems to be working for my use case, all i need is to relax the check to allow subclasses. Would be happy to properly understand the surrounding code and produce a small PR, if this is something that we deem to be a worthwhile feature.
Additional comments
NA
Concisely describe the proposed feature
Kernels currently take dataclasses that match exactly the annotated type, but this misses out on the potential of elegant composition of dataclasses.
In particular, we find that in our codebase a pattern arises where we have a large dataclass, but with only a subset of the parameters being valid for use in quadrants kernels. Take the following example:
Here, we try and separate out the kernel-relevant parameters from the parameters that cannot be used in the kernel. An easy way of doing this would be nested composition. So:
Domaincontains an attributeqd_safe: QdDomain. However, I find this slightly inelegant to require consumers to writedomain.qd_safe.xwhen quadrants-safety is likely irrelevant to their task. The inheritance composition would be much nicer.Furthermore, if we want quadrants to be type-checkable, there seems to be no way to annotate that kernels are invariant on their dataclass arguments. Python will always accept the above as valid. This is another reason we might want to make this meaningful.
Describe the solution you'd like (if any)
I believe an internal fix is very easy. In fact, it seems to be working for my use case, all i need is to relax the check to allow subclasses. Would be happy to properly understand the surrounding code and produce a small PR, if this is something that we deem to be a worthwhile feature.
Additional comments
NA