I ran into this problem several times by now: I save some kind of information I need in a class that holds a tuple of data, since the two are connected (e.g. a channel number for my Zotino board and some internal list index with the voltage corresponding to that channel). Outside of the kernel this is no issue, but as soon as I want to access a tuple member in a kernel function, I get the error

<repository>\tests.py:31:15-31:28: error: type (numpy.int32, numpy.int32) is not iterable
        print(self.my_tuple[0])

As an example if I uncomment the last line here, the experiment will not compile:

class GenericTest(EnvExperiment):
    def build(self):
        self.setattr_device("core")
        self.my_tuple = (1, 2)

    def run(self):
        print(self.my_tuple)
        print(self.my_tuple[0])
        self.kernel_run()
        
    @kernel
    def kernel_run(self):
        self.core.reset()
        print(self.my_tuple)
        #print(self.my_tuple[0])

Interestingly (at least to me), the tuple itself poses no issue, just accessing its members. Why is it designed this way? Accessing list members is no problem, as long as the list has a fixed size and I think these two data types are closely related. Of course it is always possible to rewrite the tuple as a list with two elements, but I think it is a nice and natural language construct for a small amount of closely connected variables.

    steine01 Why is it designed this way?

    The idea was that tuples, unlike lists, could have different element types. This in turn imposes other type checking restrictions; if you have x = some_tuple[i] then it becomes generally impossible to determine the type of x at compilation time.

    This tuple design probably will change in NAC3.

      Thank you for the quick reply. I see, then I will stick to the short lists instead of tuples for these use cases.

      2 months later

      Note that deconstructing the tuple (a, b = self.my_tuple) works even on the current compiler. This might or might not be enough for your use case, of course.