Actually not a bug: constants in a function (at the place of local variables) automatically are global

[rkompass]

In trying out an older viper code example:

@micropython.viper
def matmul_vip(first:ptr16, second:ptr16, multiply:ptr16):
    row = const(10)
    col = const(10)
    for i in range(0, row):
        for j in range(0, row):
            sum = 0
            for k in range(0, col):
                sum += first[i*col+k] * second[k*row+j]
            multiply[i*row+j] = sum

I noticed that row and col now are global variables. This happens also in ordinary (not viper) functions.
This prevents e.g. the repeated definition of the same function with another (e.g. native) decorator.
Avoiding const() is not desirable, as it is used by viper and makes the code run faster.
Reading the docs again I now see that const() is described as behaving like a #define in C, so it is taken out of the interpreting process.
So this is not really a bug, but a quite unintuitive feature?
Would it be very difficult to restrict the const() definitions to the function body scope?

[jimmo]

That's right. The same thing applies to class-level variables. The problem is that the parser rule that handles const() doesn't know the scope. We had a bit of a detailed conversation about this on Discord (https://micropython.org/discord) a couple of weeks ago -- see https://discordapp.com/channels/574275045187125269/1012726673709469818/1026373402585468969

[dpgeorge]

The parser could know the scope by keeping track of when it enters a function/class body... it would probably be a good idea to clean this up and make const work better within scopes, but that's a fair bit of work and low priority (also IMO would be good to change the syntax to row: const = 10...).

For now, I suggest just making all const variables global, and making their names unique, eg:

matmul_vip_row = const(10)
...

[rkompass]

This is what I did. Thank you. Also thank you for the link @jimmo.