Python's most DISLIKED __dunder__ (and what to use instead)
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about __del__ not being called when expected, and to steer people toward with statements or weakref.finalize for cleanup.
Recommended by 2 people across 5 different months, 2022 to 2024.
What it is
An mCoding video by James Murphy explaining why Python's __del__ method is considered the most disliked dunder method. It covers how __del__ relates to the del statement, how it ignores exceptions, and why it may run zero or multiple times, then shows alternatives such as context managers and weakref.
What people said
Recommends nigh_anxiety · 2022-06 · Stack Overflow · on “How do I make an exit handler that runs after all weakref finalizers run”
As I understand it, finalizers are guaranteed to run before any global variables such as modules are cleaned up. If you want to check if the finalizer has run, you can save the return value of weakref.finalize to an instance variable (such as `self._finalizer`). Then you can check `self._finalizer.alive` to see if the finalizer has been run yet or not. Info completely stolen from [this video] which is really helpful channel for Python topics. Hopefully he'll do a full vid on weakref soon.
Recommends nigh_anxiety · 2023-04 · Stack Overflow · on “Why is `obj.__del__()` not being called when collection containing object reference is deleted”
The short answer is that __del__ is not being called because the variable p from the previous for loop is still referencing the second process object object.__del__ is not guaranteed to be called when del object is called, as per the official documentation [LINK] . object.__del__ is called when the reference count of the object is 0. The del keyword reduces the reference count of the object by 1. So you could resolve this by setting p = None or del p before calling the assertion to remove that reference, or call the assertion after exiting the test_process_creation() function, as that will remove all the reference counts from that stack level. I found this video from the mCoding channel [VID
Recommends InSync · 2023-05 · Stack Overflow · on “how to correctly handle objects deletion after an Exception”
`__del__` should not be used, as it is not very straightforward. See Python's most DISLIKED \_\_dunder\_\_ (and what to use instead) [this video] by mCoding and this question [LINK] .
Recommends InSync · 2023-05 · Stack Overflow · on “What is the __del__ method and how do I call it?”
For readers: Check out this video by mCoding [this video] , which explains how `__del__` works and provides some alternatives to it.
Recommends nigh_anxiety · 2024-05 · Stack Overflow · on “__del__ method execution order different when dealing with exception before call to del”
As `Object.__del__` is not guaranteed to be run, and is explicitly not called when `del object` is called, if you are trying to use it for any sort of cleanup, you probably want to use `weakref.finalize(self, *args)` instead. I always refer back to this video [this video] to review the topic.
Recommends nigh_anxiety · 2024-08 · Stack Overflow · on “def __del__(self) is automatically called and i don't know how to stop it”
The tutorial you are using is mistaken on the usage of __del__ . __del__ will sometimes get called when you use del , but that's circumstantial. The __del__ dunder method gets called when the reference count of an object reaches 0. Consider the following (using your person class): bob = person("Bob", "Fighter", "Male") party = [bob] del bob print("ending program") This will output ending program Bob deleted Because the list party is maintaining a reference to the Bob person instance until the program exits. However, it also isn't guaranteed that __del__ will be called when the interpreter exits. I would suggest reading the official documentation for __del__ here. [LINK] This video also has a
Cites renzev · 2023-11 · Stack Overflow · on “Is it an efficient and a good practice to pass huge pandas dataframes as function parameters and also return them from functions?”
Both methods should be fine There shouldn't be any (meaningful) overhead when passing huge objects to/from functions. This is because Python will never copy anything unless you tell it to. So when you pass things to/from functions, you're not actually passing the data, only a reference to the data. Here is an example to let you get a feel for it: import sys class MyHugeObject: def __init__(self): print('Creating object', file=sys.stderr) self.huge_list = ['data' for _ in range(100000000)] def __del__(self): print('Destroying object', file=sys.stderr) def mutate(obj): obj2 = mutate2(obj) obj2.huge_list[5] = 'newdata' return obj2 def mutate2(obj): obj.huge_list[8] = 'newerdata' return obj huge