Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.39%. Comparing base (af745a5) to head (84519e0).
⚠️ Report is 4 commits behind head on master.

@@           Coverage Diff           @@
##           master   #18005   +/-   ##
=======================================
  Coverage   98.38%   98.39%           
=======================================
  Files         171      171           
  Lines       22296    22314   +18     
=======================================
+ Hits        21937    21955   +18     
  Misses        359      359           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Note that 105f475 is common with #18004; this feature was the main impetus for finding that cleanup.

Code size report:

   bare-arm:   +12 +0.021% 
minimal x86:   +16 +0.008% 
   unix x64:  +120 +0.014% standard
      stm32:  +104 +0.026% PYBV10
     mimxrt:  +104 +0.028% TEENSY40
        rp2:  +120 +0.013% RPI_PICO_W
       samd:  +132 +0.049% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:  +268 +0.059% VIRT_RV32

Remaining TODO:

• Find a means to discriminate MICROPY_ENABLE_FINALISER to avoid test failures on minimal ports.
• Determine the root cause for the Unix-specific test failures and fix it.
• Revise documentation to communicate this capability instead of warning its absence.
• Develop and test performance benchmarks to profile runtime impact.

Other than for freeing resources obtained through FFI, what use case would it have in MicroPython?

Other than for freeing resources obtained through FFI, what use case would it have in MicroPython?

What use cases do finalisers have in MicroPython at all? Anything you could want to do with them in C, you could have a perfectly valid reason to want to do with python. __del__ isn't just about letting you close or destruct non-python external resources, it's also for managing the lifetimes of other python objects in designs that involve caching or ECS-like systems.

The original impetus for this feature was related to @agatti's current work implementing machine.Pin on the unix port, in order to preserve the standard machine.Pin(*a) is machine.Pin(*a) invariant with pins backed by /dev/gpiochipX ioctls. Not all device files necessarily even exist yet when the interpreter starts, so they really do need to be dynamically allocated, and freed too when user code no longer holds a reference, in order to not leak memory over multiple hotplug cycles of a gpio device.

I've got another library I've been developing that would benefit from this, that's for managing I2C devices --- with efficient transaction queueing, caching, and automatic fusion of adjacent transactions.

When a sqlite returns a handle to a stored procedure it's memoized, if you're using a python-level ORM object to manage that procedure, it ought to be able to set a __del__ method that instructs sqlite to discard that entry from its stored procedure table, too.

More broadly, this applies to any sorts of code that uses ECS/SoA data layout, i.e. with user-defined type with a non-pointer value indexing some kind of table; or when doing any kind of database that needs to track reach-ability across non-trivial foreign-key relationships.

In many cases, context managers are the "clean code approved" way to manage external lifetimes --- but if every problem was one with lifetime boundaries that were that simple, we'd already all just be writing Rust instead of Python. Plus, to implement a context manager that's robust against bugs like e.g. #2621, that too also needs to make use of __del__, as a second-resort cleanup behind __exit__.

I'm currently working on an implementation of the weakref module, which is also a tool often used in caching and ECS-like situations. With __del__, it should be possible to do this as part of micropython's python-language standard library, without necessarily requiring other c-language primitives (except maybe one for de/obfuscating object pointers from the garbage collector).

See also:

• py: __del__ special method not implemented for user-defined classes #1878
• Do we want to have weakref support? #646
• Context manager __exit__() not called in generator which does not run to completion #2621
• Selective collect #17142