Варианты использования для __del__

Контекстные менеджеры (и try / finally blocks) несколько более ограничительны, чем __del__ . В общем, они требуют, чтобы вы структурировали свой код таким образом, чтобы ресурс ресурса, который вам нужен для свободного, не выходил за пределы одного вызова функции на некотором уровне в стеке вызовов, а не, скажем, привязывал его к жизни экземпляра класса, который может быть уничтожен в непредсказуемые времена и места. Обычно бывает полезно ограничить время жизни ресурсов одной областью, но иногда возникают случаи, когда этот шаблон неудобен.

Единственный случай, когда я использовал __del__ (кроме отладки, ответ cf @ MSeifert), предназначен для освобождения памяти, выделенной вне Python внешней библиотекой. Из-за дизайна библиотеки, которую я обертывал, было трудно избежать наличия большого количества объектов, содержащих указатели на выделенную кучу память. Использование метода __del__ для освобождения указателей было самым простым способом очистки, поскольку было бы нецелесообразно включать продолжительность каждого экземпляра в диспетчере контекстов.

Одним из вариантов использования является отладка. Если вы хотите отслеживать время жизни конкретного объекта, удобно написать временный метод __del__ . Его можно использовать для выполнения некоторых протоколов или для print . Я использовал его несколько раз, особенно когда мне было интересно, когда и как удаляются экземпляры. Иногда бывает полезно знать, когда вы создаете и отбрасываете много временных экземпляров. Но, как я уже сказал, я использовал это только для удовлетворения моего любопытства или отладки.

Другим вариантом использования является подкласс класса, который определяет метод __del__ . Иногда вы обнаруживаете класс, который вы хотите использовать для подкласса, но внутренняя часть требует, чтобы вы фактически переопределили __del__ для управления порядком, в котором этот экземпляр был очищен. Это очень редко, потому что вам нужно найти класс с __del__ , вы должны подклассифицировать его, и вам нужно ввести некоторые внутренние __del__ , которые на самом деле требуют вызова суперкласса __del__ в нужное время. Я действительно сделал это один раз, но я не помню, где и почему это было важно (возможно, я даже не знал об альтернативах, поэтому рассматривайте это как возможный случай использования).

Когда вы обертываете внешний объект (например, объект c, который не отслеживается Python), который действительно действительно должен быть освобожден, даже если кто-то «забывает» (я подозреваю, что многие люди просто опускают их специально!) Для использования который вы предоставили.

Однако все эти случаи (или должны быть) очень, очень редки. На самом деле это немного похоже на метаклассы: они забавные, и это действительно здорово понять концепции, потому что вы можете исследовать «забавные части» python. Но на практике:

Если вы задаетесь вопросом, нужны ли вам эти [метаклассы], вы этого не делаете (люди, которые действительно нуждаются в них, знают с уверенностью, что они в них нуждаются, и не нуждаются в объяснении, почему).

Цитата (вероятно) от Тима Петерса (я не нашел исходную ссылку).

Один случай, когда я всегда использую __del__ , предназначен для закрытия объекта aiohttp.ClientSession .

Когда вы этого не сделаете, aiohttp напечатает предупреждения о незакрытом сеансе клиента.