Расскажу о том, как писать свои библиотеки, совместимые с чем-то из стандартной библиотеки Python:

- Фиксируем протокол и убеждаемся, что под него подпадает "официальная" реализация.

- Пилим свои реализации протокола.

Расскажу про 2 свои библиотеки, которые расширяют то, что уже есть в стандартной библиотеке:

1. https://github.com/pomponchik/locklib - расширение возможностей мьютексов из стандартной библиотеки. Содержит универсальный протокол лока + реализации.

2. https://github.com/pomponchik/emptylog - расширение стандартного логгинга. Содержит универсальный протокол логгера + несколько его реализаций.

1) Использование селекторов в чистой архитектуре (DDD)

2) Доклад об использовании паттерна "Селекторы", направленного на

* увеличение степени переиспользования частей orm запросов;

* увеличение читаемости orm запросов;

* изоляцию логики получения данных;

* увеличение гибкости программного кода.

3) Доклад представляет собой сторителлинг, в ходе которого простым языком изложен принцип паттерна селектор.

4) В ходе доклада будут разобраны следующие пункты:

* проблема;

* решение;

* теоретическое обоснование;

* практическое применение;

* преимущества подхода;

* недостатки подхода.

Такие конструкции и концепты языка python как глобальные переменные, декораторы и аннотации типов вместе с интерпретируемостью и инструментами рефлексии позволяют создателям фреймворков включать в него различные способы определения каркаса web-сервиса. Популярный FastAPI и уже зрелый Flask тяготеют к декларативности.

Роутинг, валидация, документация и инициализация приложения завязаны на модификацию view-функций с помощью декораторов и аннотаций. С такого подхода стартуют многие проекты, однако так ли он хорош в приложениях с десятками эндпоинтов, которые содержат средства для аутентификации, документирования, поддержания обратной совместимости, разграничения областей видимости и пр.?

При разрастании кодовой базы приложения, составленного при помощи аннотаций и декораторов, возможны следующие трудности: конфликты внешних зависимостей, сложности тестировании приложения, где необходимы кастомные подключения к внешним зависимостям или эмулирование аутентификации.

В докладе выделим преимущества и недостатки декларативного и императивного подхода в определении скелета web-сервиса. Сопоставив их с масштабами приложений и обсудим, в каких моментах будет выгодно отойти от идиоматического подхода фреймворка. Также, на примере Flask и FastAPI покажем, как извлекать преимущества из обоих стилей, для этого посмотрим исходный код фреймворков и решения, принятые их создателями.

В своем докладе я расскажу о DI фреймворках и о том, нужны ли они в вашей кодовой базе. Я свяжу это с SOLID, постараюсь наглядно продемонстрировать почему DI может быть полезен и постараюсь поговорить о скорости DI фреймворков. Конечно же, поговорим и о скорости работы DI.