Hello SilverBullet,
I could reproduce the Bug. Also on Blackpill with MicroPython v1.18-121-gd8a7bf83c.
But with slight difference:
If the __init(self)__ method has the @micropython.viper decorator the exception is raised already in the class instantiation (foo = Foo()).
If only bar(self) has this decorator, then foo first has member variable foobar and after the first foo.bar() statement this member is no longer there.
I tended to agree to conclude that viper class member methods that assign integer values 0 to member variables delete those variables.
But then found this:
Code: Select all
class Foo:
@micropython.viper
def __init__(self):
self.v1 = 1
return
@micropython.viper
def bar(self):
self.v1 -= self.v1
return
foo = Foo()
print(foo.v1) # should print 1 but prints 0
foo.bar()
print(foo.v1)
foo.bar()
print(foo.v1)
The __init(self)__ function does not set the value 1 when decorated with @micropython.viper. Instead v1 is set to (or remains?) 0.
Removing this decorator lets it set v1 to 1 correctly.
Testing the above hypothetic conclusion I let compute an integer value of 0. But that seems to work correctly.
So the above conclusion is not correct. Only setting variable to 0 directly in viper mode seems to remove the variable.
Plus setting to any integer value is not working.
------
It may even hang up the system:
Code: Select all
class Foo:
@micropython.viper
def __init__(self):
self.v1 = 1
return
@micropython.viper
def bar(self):
self.v1 -= self.v1
return
@micropython.viper
def con(self):
self.v1 = 4
return
foo = Foo()
print(foo.v1) # should print 1 but prints 0
foo.bar()
print(foo.v1)
foo.bar()
print(foo.v1)
foo.con()
print(foo.v1)
makes me loosing the connection in Thonny to both the Blackpill uPy 1.18 and RPi2040 uPy1.19.
Definitely a Bug to be reported in GitHub. If you prefer, I can report it. But first thank you for finding it and reporting here in the first place.
Greetings,
Raul
