Numba 0.54.0: unexpected assignment behavior within objmode context.

[BenjaminChoou]

Reporting a bug

• [Y] I have tried using the latest released version of Numba (most recent is
  visible in the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
• [Y] I have included a self contained code sample to reproduce the problem.

import numba
from numba import objmode


class Test(object):
    a = None

@numba.jit(nopython=True)
def test():
    with objmode():
        Test.a = 100
        print(Test.a)
    
    with objmode():
        print(Test.a)


test()

The above code runs as expected if Numba <= 0.53.1. The expected outputs are:

100
100

However, after update Numba to 0.54.0, the outputs are:

100
None

, which is not consistent with pure python.

[stuartarchibald]

Thanks for the report, I can reproduce.

git bisect suggests:

The first bad commit could be any of:

b9a7fc1
e13d80c
033452b
58c4e32
34db404

We cannot bisect more!

Which are all #6977.

CC @sklam

[sklam]

I found out that cloudpickle is serializing Test when it is not importable. A class (e.g. Test) is usually importable when it is defined as a global of a module. However, the failing case is when the class is defined in the __main__ module. The cloudpickle code is rejecting to import from __main__ even though it appears to be possible.

Since Test is serialized allow with the code in objmode(), it is creating a fresh Test class everytime.

[sklam]

The problem is pretty much down to this if-statement in cloudpickle: https://github.com/cloudpipe/cloudpickle/blob/343da119685f622da2d1658ef7b3e2516a01817f/cloudpickle/cloudpickle.py#L300-L301
Why does cloudpickle reject handling __main__? Commenting it out appears to work for this issue.

[sklam]

Why does cloudpickle reject handling main? Commenting it out appears to work for this issue.

answer: cloudpipe/cloudpickle#131