Модуль weakref позволяет создавать "слабые" ссылки на объекты.

"Слабой" ссылки не достаточно, чтобы объект оставался "живым": когда на объект ссылаются только "слабые" ссылки, сборщик мусора удаляет объект и использует память для других объектов. Однако, пока объект не удалён, "слабая" ссылка может вернуть объект, даже если не осталось обычных ссылок на объект.

Один из примеров использования "слабых" ссылок - это реализация кэшей, содержащих большие объекты, когда нежелательно, чтобы объект оставался в памяти только потому, что на него есть ссылки из кэша.

Например, если у вас есть несколько больших объектов картинок, вы можете ассоциировать с каждой картинкой название. Если вы будете использовать обычный словарь для отображения названий на картинки, объекты будут оставаться "живыми" только потому, что они являются значениями в словаре. Использование WeakValueDictionary, предоставленного в модуле weakref, является альтернативой. В таком случае, когда не останется обычных ссылок на картинку, сборщик мусора удалит её, и соответствующая запись в словаре будет удалена.

WeakKeyDictionary и WeakValueDictionary используюют "слабые" ссылки в своей реализации и устанавливают callback функции на "слабые" ссылки, которые сообщают словарю, когда ключ или значение удаляется сборщиком мусора. WeakSet реализует интерфейс множества как WeakKeyDictionary.

Finalize предоставляет простой путь зарегистрировать cleanup функцию, которая вызывается, когда объект удаляется. Это проще, чем установить callback функцию на "слабую" ссылку, поскольку модуль автоматически гарантирует, что finalizer не будет удалён до того, как будет удалён объект.

Итак, что же такое «декоратор»?

def makebold(fn):
    def wrapped():
        return "<b>" + fn() + "</b>"
    return wrapped
 
def makeitalic(fn):
    def wrapped():
        return "<i>" + fn() + "</i>"
    return wrapped
 
@makebold
@makeitalic
def hello():
    return "hello habr"
 
print hello() ## выведет <b><i>hello habr</i></b>

DDD — одна из моих основных рабочих методологий, я применяю её больше пяти лет. Хотя она довольна сложная, в том числе потому что это верхнеуровневый набор практик. DDD - это не фреймворк, когда нет опыта, его немного сложно применять. Тем не менее мы переводили на DDD работающие проекты, запускали с помощью нее новые — и у нас сложились некоторые практики и подходы.

Хотелось бы рассказать про те, что доказали у нас свою эффективность. Сегодня это будет стратегическое верхнеуровневое проектирование — о том, как разрабатывать программы с точки зрения моделей и требований. А в следующей части я расскажу про практики для работы с кодом и архитектурой, то есть более приближенные к разработке. Надеюсь, что вы сможете ими воспользоваться, а если вы еще не используете DDD у себя в проектах, то попробуете.