Не знаю, почему Вы считаете задокументированную возможность переопределить метод delete за совет так поступать. Я привел Вам пример такого переопределения. Хорошо, когда такая возможность есть, намного хуже, если бы ее не было. Согласен в том, что на переопределения этих методов нужны веские основания
Скорее всего так и было. Под валидацией понимали валидацию ввода, но для удобства (тот же DRY), сделали определение валидаторов один раз в модели, а не в каждой форме. Резонно, что появляется ожидание использовать эту валидацию для собственно модели. Но теперь менять поведения метода save() — это ломать обратную совместимость
Это не побочный эффект, это переопределение операции удаление — теперь мы под этим понимаем установку отметки об удалении. Для этого надо переопределить метод delete модели. Но это не все, что нужно сделать, чтобы добиться такого поведения. Придется переопределять модель QuerySet и менять менеджер objects у модели. Тогда внешне работа с такой моделью не будет отличаться от обычной модели. Под alter behavior именно это подразумевается, а не то, что вы можете в этом методе отсылать e-mail или не удалять модель вопреки названию метода
В методе delete модель нужно удалять, что бы под этим не подразумевалось (вот для этого можно и переопределить). Никаких других полезных действий там быть не должно. Насчет принципа наименьшего удивления раскройте мысль пожалуйста (вы про пользовательский интерфейс — админку?)
Когда не нужно дополнительное поле в модели и не нужен дополнительный оверхэд, если race condition для модели не предусматривается. Насчет опциональности соглашусь, только я бы это реализовал абстрактным наследованием от Model
Приводите примеры поудачнее. Сигналы не для всего подходят, потому что отсутствует контекст, в котором вызван метод delete (тот же пользователь). Ну и вот это
Проблема не во вкусе и не в цвете, а конкретно в optimistic locking. Добавить его не сложно, когда оно надо. Выпилить его, когда оно не надо, будет сложнее
The delete_model method is given the HttpRequest and a model instance. Use this method to do pre- or post-delete operations.
Это если про админку. Если нет — то «pre- or post-delete operations» делаются в той вьюхе, с помощью которой пользователь удаляет модель. Работает всегда
По поводу 1 пункта: ModelAdmin.has_delete_permission не решает поставленной задачи?
По поводу 2 пункта: мне кажется, проще вызвать Model.full_clean там, где требуется, чем неизвестно как переопределять Model.save
А Вы можете привести пример фреймворка, который убережет программиста от желания напихать полезных действий в медот delete модели данных?
По второму пункту соглашусь
Это если про админку. Если нет — то «pre- or post-delete operations» делаются в той вьюхе, с помощью которой пользователь удаляет модель. Работает всегда
По поводу 2 пункта: мне кажется, проще вызвать Model.full_clean там, где требуется, чем неизвестно как переопределять Model.save