Сигналы ¶
Список всех сигналов, которые отправляет Django. Все встроенные сигналы отправляются с использованием send() метода.
См. Документацию по диспетчеру сигналов для получения информации о том, как регистрироваться и получать сигналы.
Сигналы модели ¶
Многие из этих сигналов отправляются различными методами модели, такими как __init__() или save() которые вы можете переопределить в своем собственном коде.
Если вы переопределите эти методы в своей модели, вы должны вызвать методы родительского класса для отправки этих сигналов.
pre_init ¶
Аргументы, отправленные с этим сигналом:
Например, в учебнике есть такая строка:
Аргументы, отправленные pre_init обработчику, будут следующими:
| Аргумент | Значение |
|---|---|
| sender | Question (сам класс) |
| args | [] (пустой список, потому что не были переданы позиционные аргументы __init__() ) |
| kwargs |
post_init ¶
Подобно pre_init, но этот отправляется, когда __init__() метод завершается.
Аргументы, отправленные с этим сигналом:
sender Как указано выше: класс модели, для которого только что был создан экземпляр. instance
Фактический экземпляр только что созданной модели.
pre_save ¶
Аргументы, отправленные с этим сигналом:
post_save ¶
Аргументы, отправленные с этим сигналом:
pre_delete ¶
Аргументы, отправленные с этим сигналом:
sender Класс модели. instance Фактический удаляемый экземпляр. using Используемый псевдоним базы данных.
post_delete ¶
Аргументы, отправленные с этим сигналом:
sender Класс модели. instance
Фактический удаляемый экземпляр.
Обратите внимание, что объекта больше не будет в базе данных, поэтому будьте очень осторожны с этим экземпляром.
using Используемый псевдоним базы данных.
m2m_changed ¶
Аргументы, отправленные с этим сигналом:
Строка, указывающая тип обновления, которое выполняется для отношения. Это может быть одно из следующих:
«pre_add» Отправляется перед добавлением в отношение одного или нескольких объектов. «post_add» Отправляется после добавления в отношение одного или нескольких объектов. «pre_remove» Отправляется до того, как один или несколько объектов будут удалены из отношения. «post_remove» Отправляется после удаления одного или нескольких объектов из отношения. «pre_clear» Отправлено до того, как связь будет очищена. «post_clear» Отправляется после очистки связи. reverse Указывает, какая сторона отношения обновляется (т. Е. Изменяется ли это прямое или обратное отношение). model Класс объектов, которые добавляются, удаляются или удаляются из отношения. pk_set
using Используемый псевдоним базы данных.
Например, если a Pizza может иметь несколько Topping объектов, смоделированных следующим образом:
Если бы мы подключили такой обработчик:
а потом сделал что-то вроде этого:
аргументы, отправленные m2m_changed обработчику ( toppings_changed в приведенном выше примере), будут:
И если бы мы тогда сделали что-то вроде этого:
аргументы, отправленные m2m_changed обработчику, будут следующими:
class_prepared ¶
Отправляется всякий раз, когда класс модели был «подготовлен», то есть после того, как модель была определена и зарегистрирована в модельной системе Django. Django использует этот сигнал для внутренних целей; он обычно не используется в сторонних приложениях.
Аргументы, которые отправляются с этим сигналом:
sender Класс модели, который только что был подготовлен.
Управляющие сигналы ¶
pre_migrate ¶
Отправляется migrate командой перед началом установки приложения. Он не выдается для приложений, в которых отсутствует models модуль.
Аргументы, отправленные с этим сигналом:
Функции, которые прослушивают, pre_migrate должны настраивать то, что они выводят на экран, в зависимости от значения этого аргумента.
post_migrate ¶
Отправляется в конце migrate (даже если миграции не выполняются) и flush команд. Он не выдается для приложений, в которых отсутствует models модуль.
Обработчики этого сигнала не должны выполнять изменения схемы базы данных, поскольку это может привести flush к сбою команды, если она выполняется во время выполнения migrate команды.
Аргументы, отправленные с этим сигналом:
Функции, которые прослушивают, post_migrate должны настраивать то, что они выводят на экран, в зависимости от значения этого аргумента.
Например, вы можете зарегистрировать обратный вызов AppConfig следующим образом:
Сигналы запроса / ответа ¶
Сигналы, отправляемые основной структурой при обработке запроса.
request_started ¶
Отправляется, когда Django начинает обрабатывать HTTP-запрос.
Аргументы, отправленные с этим сигналом:
sender Класс обработчика, например, django.core.handlers.wsgi.WsgiHandler который обработал запрос. environ environ Словарь предоставляется на запрос.
request_finished ¶
Отправляется, когда Django завершает доставку HTTP-ответа клиенту.
Аргументы, отправленные с этим сигналом:
sender Класс обработчика, как указано выше.
got_request_exception ¶
Этот сигнал отправляется всякий раз, когда Django обнаруживает исключение при обработке входящего HTTP-запроса.
Аргументы, отправленные с этим сигналом:
sender Не используется (всегда None ). request HttpRequest Объект.
Тестовые сигналы ¶
setting_changed ¶
Этот сигнал отправляется, когда значение параметра изменяется через django.test.TestCase.settings() диспетчер контекста или django.test.override_settings() декоратор / диспетчер контекста.
Фактически он отправляется дважды: когда применяется новое значение («настройка») и когда восстанавливается исходное значение («удаление»). Используйте enter аргумент, чтобы различать их.
Вы также можете импортировать этот сигнал из, django.core.signals чтобы избежать импорта из django.test не тестовых ситуаций.
Аргументы, отправленные с этим сигналом:
template_rendered ¶
Аргументы, отправленные с этим сигналом:
Оболочки базы данных ¶
Сигналы, отправляемые оболочкой базы данных при инициировании соединения с базой данных.
connection_created ¶
Отправляется, когда оболочка базы данных устанавливает первоначальное соединение с базой данных. Это особенно полезно, если вы хотите отправлять какие-либо команды подключения к серверу SQL.
Использование сигналов Django для упрощения и разделения кода
Вступление
С течением времени системы становятся все более сложными, и это оправдывает необходимость большего разделения систем. Развязанную систему легче построить, расширить и поддерживать в долгосрочной перспективе, поскольку развязка не только снижает сложность системы, но и позволяет управлять каждой ее частью индивидуально. Отказоустойчивость также возросла, поскольку в разобщенной системе отказавший компонент не тянет за собой всю систему.
Django-это мощный веб-фреймворк с открытым исходным кодом, который можно использовать для создания больших и сложных систем, а также небольших. Он следует архитектурному шаблону модель-шаблон-представление и верен своей цели-помочь разработчикам достичь доставки сложных веб-приложений, управляемых данными.
Django позволяет нам отделить функциональность системы, создавая отдельные приложения в рамках проекта. Например, у нас может быть система покупок и отдельные приложения, которые обрабатывают учетные записи, отправку по электронной почте квитанций и уведомлений, среди прочего.
В такой системе несколько приложений могут быть необходимы для выполнения действия, когда происходят определенные события. Одно событие может произойти, когда клиент делает заказ. Например, нам нужно будет уведомить пользователя по электронной почте, а также отправить заказ поставщику или продавцу, в то же время мы сможем получать и обрабатывать платежи. Все эти события происходят в одно и то же время, и поскольку наше приложение отделено, нам нужно держать каждый компонент в синхронизации, но как мы этого достигаем?
Django Signals пригодится в такой ситуации, все, что нужно сделать, это послать сигнал, когда пользователь размещает заказ, и каждый связанный или затронутый компонент слушает его и выполняет свои операции. Давайте подробнее рассмотрим сигналы в этом посте.
Сигналы с первого взгляда
С помощью “диспетчера сигналов” Django может распределять сигналы в несвязанном наборе на зарегистрированные “приемники” в различных компонентах системы. Сигналы регистрируются и срабатывают всякий раз, когда происходят определенные события, и любой слушатель этого события получит уведомление о том, что событие произошло, наряду с получением некоторых контекстуальных данных в полезной нагрузке, которые могут иметь отношение к функциональности приемника. Приемником может быть любая функция или метод Python. Подробнее об этом позже.
Помимо диспетчера сигналов, Django также поставляется с некоторыми полезными сигналами, которые мы можем слушать. Они включают в себя:
Еще одно преимущество Django заключается в том, что это очень настраиваемый фреймворк. В нашем случае мы можем создавать свои собственные сигналы и использовать встроенную систему для отправки и приема их в нашей отделенной системе. В демонстрационном разделе мы подпишемся на некоторые встроенные сигналы Django, а также создадим собственные.
Но сначала давайте рассмотрим краткий пример использования сигналов Django. Здесь у нас есть две функции, которые играют в пинг-понг друг с другом, но взаимодействуют через сигналы:
Когда использовать сигналы
Мы уже определили, что такое сигналы Django и как они работают, но, как и любая другая функция фреймворка, она не предназначена для использования на каждом шагу. Существуют конкретные сценарии, в которых настоятельно рекомендуется использовать сигналы Django, и они включают в себя:
Преимущества сигналов
Сигналы Django упрощают реализацию наших разобщенных систем различными способами. Они помогают нам реализовывать многоразовые приложения, и вместо того, чтобы повторно использовать функциональность отдельно или изменять другие части системы, мы можем просто реагировать на сигналы, не затрагивая другой код. Таким образом, компоненты системы могут быть изменены, добавлены или удалены, не касаясь существующей кодовой базы.
Сигналы также обеспечивают упрощенный механизм для поддержания различных компонентов разобщенной системы в синхронизации и актуальности друг с другом.
Демонстрационный проект
В нашем демо-проекте мы создадим простую доску вакансий, где пользователи будут заходить на сайт, просматривать доступные вакансии и выбирать вакансию для подписки. Пользователи подпишутся, просто отправив свой адрес электронной почты, и будут уведомлены о любых изменениях в задании. Например, если требования изменяются, открытие вакансии закрывается или если проводка вакансии снимается. Все эти изменения будут выполняться администратором, у которого будет панель мониторинга для создания, обновления и даже удаления объявлений о вакансиях.
В духе разделения нашего приложения мы создадим основное приложение Jobs Board и отдельное приложение уведомлений, которому будет поручено уведомлять пользователей по мере необходимости. Затем мы будем использовать сигналы для вызова функций в приложении уведомлений из основного приложения Jobs Board.
Еще одним свидетельством обширного набора функций Django является встроенная панель администрирования, которую наши администраторы будут использовать для управления заданиями. Наша работа на этом фронте значительно сокращается, и мы можем быстрее создать прототип вашего приложения.
Настройка проекта
Рекомендуется создавать проекты Python в виртуальной среде, чтобы мы работали в изолированной среде, которая не влияет на настройку Python системы, поэтому мы будем использовать Pipenv.
Давайте сначала установим наше окружение:
Django поставляется с некоторыми командами, которые помогают нам выполнять различные задачи, такие как создание проекта, создание приложений, миграция данных и тестирование кода. Чтобы создать наш проект:
Приведенные выше команды создадут проект Django с двумя приложениями внутри него, которые отделены друг от друга, но все еще могут работать вместе. Чтобы убедиться, что наша настройка прошла успешно, давайте перенесем миграции по умолчанию, поставляемые с Django, и настроим нашу базу данных и таблицы:
Когда мы получаем доступ к локальному запущенному экземпляру нашего проекта Django, мы должны увидеть следующее:
Это означает, что мы успешно настроили ваш проект Django и теперь можем приступить к реализации нашей логики.
Реализация
Django основан на шаблоне архитектуры model-view-template, и этот шаблон также будет направлять нашу реализацию. Мы создадим модели для определения наших данных, затем реализуем представления для обработки доступа к данным и манипулирования ими, и, наконец, шаблоны для отображения наших данных конечному пользователю в браузере.
Часть 1: Основное приложение Jobs Board
Именно здесь будет находиться основная часть функциональности нашей системы, и это будет точка взаимодействия с нашими пользователями. Он будет содержать наши модели, представления и шаблоны, а также некоторые индивидуальные сигналы, которые мы будем использовать для взаимодействия с приложением уведомлений.
Давайте начнем с создания наших моделей в jobs_board_main/models.py :
С нашими моделями на месте нам нужно сделать миграции и перенести их, чтобы иметь таблицы, созданные в базе данных:
Далее мы переходим к разделу просмотра нашего приложения. Давайте создадим представление для отображения всех сообщений о вакансиях, а другое-для отображения отдельных сообщений о вакансиях, на которые пользователи могут подписаться, отправив свои электронные письма.
Мы начнем с создания представления, которое будет обрабатывать отображение всех наших заданий:
Для этого проекта мы будем использовать представления на основе функций, альтернативой которым являются представления на основе классов, но это не является частью нашего обсуждения. Мы запрашиваем базу данных для всех заданий и отвечаем на запрос, указывая шаблон, который будет отображать задания, а также включая задания в ответ.
Шаблон для визуализации всех заданий будет отображать все задания со ссылками на отдельные проводки заданий следующим образом:
В этом файле мы импортируем наше представление, создаем путь и прикрепляем к нему наше представление. Теперь мы зарегистрируем URL-адреса вашего приложения в главном urls.py файл в папке проекта jobs_board :
Наш проект уже готов к тестированию. Это то, что мы получаем, когда запускаем приложение и переходим к localhost:8000/jobs :
В настоящее время у нас нет рабочих мест. Django поставляется с приложением администрирования, которое мы можем использовать для ввода данных. Во-первых, мы начинаем с создания суперпользователя:
После создания суперпользователя нам нужно зарегистрировать наши модели в admin.py файл в нашем jobs_board_main приложении:
Мы перезапускаем наше приложение и переходим к localhost:8000/admin и входим в систему с учетными данными, которые мы только что установили. Таков результат:
Когда мы нажимаем на знак плюс в строке “Вакансии”, мы получаем форму, в которой заполняем подробную информацию о нашей вакансии:
Теперь мы создадим представления, шаблоны и URL-адреса для отображения одного задания, а также позволим пользователям подписаться, отправив свою электронную почту.
Наш jobs_board_main/views.py будет расширен следующим образом:
Как только пользователь подпишется на задание, нам нужно будет перенаправить его на страницу подтверждения. subscribed.html шаблон будет выглядеть следующим образом:
Наконец, наша новая функциональность должна быть открыта через конечные точки, которые мы добавим к нашим существующим jobs_board_main/urls.py следующим образом:
Теперь мы можем протестировать наше основное приложение Jobs Board, просмотрев списки вакансий, нажав на одну из них и отправив адрес электронной почты, который будет получать обновления.
Теперь, когда у нас есть работающее приложение, пришло время вводить сигналы Django и уведомлять пользователей/подписчиков о том, когда происходят определенные события. Объявления о вакансиях привязаны к определенной компании, чью электронную почту мы записываем, и мы хотим уведомить их, когда новый пользователь подпишется на их объявление о вакансиях. Мы также хотим уведомить подписанных пользователей, когда объявление о вакансии будет удалено.
Мы создаем наши пользовательские сигналы, создавая signals.py файл в нашем jobs_board_main приложении:
Вот оно! Наш пользовательский сигнал готов к вызову после того, как пользователь успешно подписался на публикацию вакансии следующим образом в нашем jobs_board_main/views.py файл:
Часть 2: Приложение Уведомления о Работе Совета директоров
Мы уже создали приложение jobs_board_notifications и подключили его к нашему проекту Django. В этом разделе мы будем использовать сигналы, отправленные из нашего основного приложения, и отправлять уведомления. Django имеет встроенную функциональность для отправки электронных писем, но для целей разработки мы будем печатать сообщения на консоли.
Наше приложение jobs_board_notifications не нуждается во взаимодействии с пользователем, поэтому нам не нужно создавать какие-либо представления или шаблоны для этой цели. Единственная цель для наших jobs_board_notifications состоит в том, чтобы получать сигналы и отправлять уведомления. Мы реализуем эту функциональность в нашем models.py так как он импортируется рано, когда приложение запускается.
Давайте принимать наши сигналы в нашем jobs_board_notifications/models.py :
Получив контекстные данные, мы используем их для отправки “электронных писем” (напомним, что мы просто печатаем на консоли для простоты) подписчикам и компаниям, когда пользователь подписывается и сообщение о работе удаляется, отвечая на сигналы, которые мы посылали.
Тестирование
После того, как мы создали задание в нашей панели администратора, оно доступно для подписки пользователей. Когда пользователи подписываются, из приложения jobs_board_notifications в компанию, владеющую публикацией, отправляется следующее электронное письмо:
При удалении записи о задании все пользователи, подписавшиеся на нее, получают уведомление по электронной почте следующим образом:
Сигнал Django pre_delete оказался очень кстати, и наш обработчик разослал подписанным пользователям уведомления о том, что конкретная вакансия была удалена.
Резюме
В этой статье мы построили проект Django с двумя приложениями, которые общаются через сигналы Django в ответ на определенные события. Наши два приложения разделены, и сложность связи между нашими приложениями значительно уменьшилась. Когда пользователь подписывается на вакансию, мы уведомляем об этом компанию. В свою очередь, когда объявление о вакансии было удалено, мы уведомляем всех подписавшихся клиентов о том, что объявление о вакансии было удалено.
Однако есть некоторые вещи, которые мы должны иметь в виду при использовании сигналов Django. Когда сигналы недостаточно хорошо документированы, новым сопровождающим может быть трудно определить первопричину определенных проблем или неожиданного поведения. Поэтому, когда сигналы используются в приложении, хорошо документировать используемые сигналы, где они принимаются и причину их появления. Это поможет любому, кто поддерживает код, понять поведение приложения и решить проблемы быстрее и лучше. Кроме того, полезно отметить, что сигналы посылаются синхронно. Они не выполняются в фоновом режиме или какими-либо асинхронными заданиями.
Имея всю эту информацию о сигналах Django и демо-проекте, мы должны быть в состоянии использовать силу сигналов в наших веб-проектах Django.
Документация Django 1.9
Django содержит “диспетчер сигналов”, который позволяет одним приложениям фреймворка получать уведомления от других после того, как в последних произойдут некоторые события. Вкратце, сигналы позволяют определённым отправителям уведомлять некоторый набор получателей о совершении действий. Сигналы особенно полезны, когда поведение многих фрагментов кода зависит от инициации одних и тех же событий.
Django предоставляет набор встроенных сигналов, которые позволяют пользовательскому коду получать уведомление от Django об определённых событиях. Эти сигналы включают в себя некоторые полезные уведомления:
Отправляются до или после вызова метода save() модели.
Отправляются до или после вызова метода delete() модели или delete() класса QuerySet.
Отправляются после изменения ManyToManyField в модели.
Отправляются, когда Django начинает или заканчивает HTTP запрос.
Полный список этих сигналов, а также описание каждого сигнала, см. в документации по встроенным сигналам.
Вы можете также определять и посылать свои собственные сигналы ; см. ниже.
Прослушивание сигналов¶
Для того, чтобы принять сигнал, Вам необходимо с помощью метода Signal.connect() зарегистрировать функцию receiver, которая вызывается, когда сигнал послан:
Функции-получатели¶
Во-первых, мы должны определить функцию-получатель. Получатель должен быть Python функцией или методом:
Это было бы неверно – на самом деле, Django выдаст ошибку, если Вы это сделаете. Так произойдёт, потому что при любом вызове аргументы могут быть добавлены к сигналу и получатель должен быть в состоянии обработать эти новые аргументы.
Регистрация функции-получателя¶
Есть два способа, которыми Вы можете подключить получатель к сигналу. Вы можете вручную вызвать connect:
Кроме того, вы можете использовать декоратор receiver() при определении вашего получателя:
receiver (signal)¶
| Параметры: | signal – Сигнал или список обрабатываемых сигналов. |
|---|
Вот как можно использовать декоратор:
Теперь наша функция my_callback будет вызываться каждый раз, когда запрос завершается.
Куда положить этот код?
Сигналы, получаемые от определённых отправителей.¶
В этих случаях Вы можете получать только сигналы, посланные определёнными отправителями. В случае django.db.models.signals.pre_save отправитель будет сохраняемой моделью некоторого класса, так что вы можете указать, что вы хотите получать только сигналы, посылаемые этой моделью:
Отправителями различных сигналов могут быть различные объекты. Для получения детальной информации по каждому такому сигналу обращайтесь к документации по встроенным сигналам.
Предотвращение дублирования сигналов¶
В некоторых случаях модуль, в котором Вы подключаете сигналы, может быть импортирован несколько раз. Это может привести к тому, что получатель сигнала будет зарегистрирован несколько раз, и таким образом, вызов сигнала произойдет несколько раз при наступлении одного и того же события.
Создание и посылка сигналов.¶
Вы можете создавать свои собственные сигналы в ваших приложениях.
Создание сигналов¶
Вы можете задать в этом списке аргументов любые значения передаваемых параметров.
Отправка сигналов¶
В Django существует два способа отправки сигналов.
Signal. send (sender, **kwargs)¶ Signal. send_robust (sender, **kwargs)¶
Например, вот как может выглядеть отправка сигнала pizza_done :
send() отличается от send_robust() способом обработки исключений, генерируемых функцией-получателем. send() не ловит никаких исключений, сгенерированных в получателе, позволяя исключению проваливаться дальше. Таким образом, не все получатели могут получить сигнал при возникновении ошибки.
send_robust() перехватывает все ошибки, наследуемые от класса Exception языка Python, и гарантирует, что сигнал дойдёт до всех получателей. Если произойдёт ошибка в одном из них, экземпляр исключения будет помещён в кортежную пару, для получателя, который соответствует вызываемой ошибке.
Отключение сигнала¶
Было добавлено возвращение булева значения.
Не рекомендуется, начиная с версии 1.9: Аргумент weak устарел и не имеет никакого эффекта. Он будет удален в Django 2.0.
документация Django 3.0
Django содержит «диспетчер сигналов», который позволяет одним приложениям фреймворка получать уведомления от других после того, как в последних произойдут некоторые события. Вкратце, сигналы позволяют определённым отправителям уведомлять некоторый набор получателей о совершении действий. Сигналы особенно полезны, когда поведение многих фрагментов кода зависит от инициации одних и тех же событий.
Django предоставляет набор встроенных сигналов, которые позволяют пользовательскому коду получать уведомление от Django об определённых событиях. Эти сигналы включают в себя некоторые полезные уведомления:
Отправляются до или после вызова метода save() модели.
Отправляются до или после вызова метода delete() модели или delete() класса QuerySet.
Отправляются после изменения ManyToManyField в модели.
Отправляются, когда Django начинает или заканчивает HTTP запрос.
Вы можете также определять и посылать свои собственные сигналы ; см. ниже.
Прослушивание сигналов¶
To receive a signal, register a receiver function using the Signal.connect() method. The receiver function is called when the signal is sent. All of the signal’s receiver functions are called one at a time, in the order they were registered.
Функции-получатели¶
Во-первых, мы должны определить функцию-получатель. Получатель должен быть Python функцией или методом:
Это было бы неверно – на самом деле, Django выдаст ошибку, если Вы это сделаете. Так произойдёт, потому что при любом вызове аргументы могут быть добавлены к сигналу и получатель должен быть в состоянии обработать эти новые аргументы.
Регистрация функции-получателя¶
Есть два способа, которыми Вы можете подключить получатель к сигналу. Вы можете вручную вызвать connect:
Кроме того, вы можете использовать декоратор receiver() при определении вашего получателя:
receiver ( signal )¶
| Параметры: | signal – Сигнал или список обрабатываемых сигналов. |
|---|
Вот как можно использовать декоратор:
Теперь наша функция my_callback будет вызываться каждый раз, когда запрос завершается.
Куда положить этот код?
Сигналы, получаемые от определённых отправителей.¶
В этих случаях Вы можете получать только сигналы, посланные определёнными отправителями. В случае django.db.models.signals.pre_save отправитель будет сохраняемой моделью некоторого класса, так что вы можете указать, что вы хотите получать только сигналы, посылаемые этой моделью:
Предотвращение дублирования сигналов¶
В некоторых случаях модуль, в котором Вы подключаете сигналы, может быть импортирован несколько раз. Это может привести к тому, что получатель сигнала будет зарегистрирован несколько раз, и таким образом, вызов сигнала произойдет несколько раз при наступлении одного и того же события.
Создание и посылка сигналов.¶
Вы можете создавать свои собственные сигналы в ваших приложениях.
When to use custom signals
Signals are implicit function calls which make debugging harder. If the sender and receiver of your custom signal are both within your project, you’re better off using an explicit function call.
Создание сигналов¶
Вы можете задать в этом списке аргументов любые значения передаваемых параметров.
Отправка сигналов¶
В Django существует два способа отправки сигналов.
Например, вот как может выглядеть отправка сигнала pizza_done :
send() отличается от send_robust() способом обработки исключений, генерируемых функцией-получателем. send() не ловит никаких исключений, сгенерированных в получателе, позволяя исключению проваливаться дальше. Таким образом, не все получатели могут получить сигнал при возникновении ошибки.
send_robust() перехватывает все ошибки, наследуемые от класса Exception языка Python, и гарантирует, что сигнал дойдёт до всех получателей. Если произойдёт ошибка в одном из них, экземпляр исключения будет помещён в кортежную пару, для получателя, который соответствует вызываемой ошибке.
