what is the actual intention behind deinit() and its implementation ? #9360
-
I assume that somehow deinit() is (is supposed to be) complementary to init, which initializes an object. From that perhaps simplistic view I have an expectation that therefore said object would be "removed", is no longer accessible after a deinit. Like a waiter who politely asks if your plate can be taken in order to prepare for dessert: if yes, its gone. I can determine that a timer tim1 I created really stops when I issue tim1.deinit(). Tim1 continues to "exist"; I can print it. Same for pwm1; pwm1.deinit() actually stops it. When I use .deinit() against a statemachine sm1, it does not stop (in fact it issues an error (AttributeError: 'StateMachine' object has no attribute 'deinit'). It stops when I issue - the bit weird - sm1.active(0) instruction. The sm1 observation may indicate an issue with the implementation (micropython 1.19, platform rp2040), but my question remains: why do these objects still exist following the deinit. If only to free up allocated resources or from an esthetical point of view: you create something, you clean it up afterward. Something specific to (micro)Python or my misunderstanding of the real intention behind deinit ? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
init() does not create an object like tim1, it configures it. And then deinit() is its complementary. The object it created by the constructor e.g. tim1 = machine.Timer(.....). The object that you created, like tim1 in your example, continues to exist because it is in the actual namespace of your code. The class method deinit() cannot remove it from that namespace holding it. It will go away as soon as this name gets out of focus. Then gc can clear that object. |
Beta Was this translation helpful? Give feedback.
init() does not create an object like tim1, it configures it. And then deinit() is its complementary. The object it created by the constructor e.g. tim1 = machine.Timer(.....).
The object that you created, like tim1 in your example, continues to exist because it is in the actual namespace of your code. The class method deinit() cannot remove it from that namespace holding it. It will go away as soon as this name gets out of focus. Then gc can clear that object.