Forwarded from Alexander Ptakhin
На https://getmentor.dev/ тоже можно поискать, если ищешь по стеку
https://getmentor.dev
GetMentor – открытое сообщество IT-наставников
GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе в разговоре 1-на-1.
Forwarded from Stanislav Bashkyrtsev
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место.
- Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а тот не хочу". Все что есть в репозитории модулей (site-packages) доступно, ну и соответственно нет возможности несколько версий одной библиотеки иметь (для разных приложений). За сим имеем кучу инструментов (pyenv, venv, virtualenv, etc) которые "решают" эту проблему страшными хаками типа "а давайте для этого проекта создадим его виртуальное окружение с его копией питона, файлами которые переопределяют стандартные питон модули, и так изолируем его зависимости"
- Инструменты сборки постоянно меняются, существует несколько инструментов по скачиванию зависимостей. И представляете - опубликованную версию зависимости можно удалить из центральной репы! У меня такое было лет 10 назад с mysql драйвером. Вот это я удивился..
- Нет ничего на подобие Spring IoC + Spring MVC. Т.е. нет возможности написать веб приложение с Dependency Injection'ом. Я счас просто свой IoC сделал в проекте. Что в целом не мешает, однако он же никак с MVC не интегрируются. Вроде как FastAPI обещал сделать Dependency Injection, а на самом деле сделал вообще не его. Но при этом сказал что это DI 😵 Т.е. вы не можете описать любые singleton бины и их заинжектить - он просто дергает метод, который каждый раз создает новые объекты (и вроде все равно не каждый объект можно так создать).
- Логирование.. казалось бы что может тут пойти не так. Но пришлось 2 дня разбираться как его настроить. 99% примеров в интернетах создают свою глобальную функцию по созданию логера, чтоб его централизованно так настраивать. Это вместо того чтоб использовать файл настроек.. Дикость. Ну и соответственно ни один фреймворк/библиотека ничего норм не логируют. А потому что не понимают как..
- Библиотеки и фреймворки все как один плохо спроектированы. Возьмем нормальные платформы типа Java - есть либа для JSON (де)сериализации (например, Jackson), есть библиотека для валидации входящих данных (Bean Validation), есть для считывания свойств (Spring IoC). А в питоне? Там есть популярный Pydantic, который реализует все три штуки вместе! Как можно было придумать запихнуть три несвязанные друг с другом responsibilities в одну либу - в голову не приходит.
И ладно бы одна такая либа, но нет же.. SQLalchemy - это JOOQ и ORM в одном теле. При этом есть либа для миграции БД - и она зависит от SQLalchemy! Тут душа требует много восклицательных знаков. Ну вы представляете если бы Flyway зависил от JOOQ или Hibernate? И реально нет в питоне нормального инструмента по миграциям (я не нашел во всяком случае) - только недоделанный yoyo
- Отсутствие интерфейсов
- Нет строгого JDBC - есть только DB-API который кой-как описан. Но если хотите - можете не следовать (и есть много драйверов которые этого не делают!). Ну и соответственно нет универсальных DB Pool типа c3p0. Представляете - у постргреса в самом драйвере написан свой DB Pool 😵
Ой, я могу продолжать конечно, но надо бы и поработать 🙂
- Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а тот не хочу". Все что есть в репозитории модулей (site-packages) доступно, ну и соответственно нет возможности несколько версий одной библиотеки иметь (для разных приложений). За сим имеем кучу инструментов (pyenv, venv, virtualenv, etc) которые "решают" эту проблему страшными хаками типа "а давайте для этого проекта создадим его виртуальное окружение с его копией питона, файлами которые переопределяют стандартные питон модули, и так изолируем его зависимости"
- Инструменты сборки постоянно меняются, существует несколько инструментов по скачиванию зависимостей. И представляете - опубликованную версию зависимости можно удалить из центральной репы! У меня такое было лет 10 назад с mysql драйвером. Вот это я удивился..
- Нет ничего на подобие Spring IoC + Spring MVC. Т.е. нет возможности написать веб приложение с Dependency Injection'ом. Я счас просто свой IoC сделал в проекте. Что в целом не мешает, однако он же никак с MVC не интегрируются. Вроде как FastAPI обещал сделать Dependency Injection, а на самом деле сделал вообще не его. Но при этом сказал что это DI 😵 Т.е. вы не можете описать любые singleton бины и их заинжектить - он просто дергает метод, который каждый раз создает новые объекты (и вроде все равно не каждый объект можно так создать).
- Логирование.. казалось бы что может тут пойти не так. Но пришлось 2 дня разбираться как его настроить. 99% примеров в интернетах создают свою глобальную функцию по созданию логера, чтоб его централизованно так настраивать. Это вместо того чтоб использовать файл настроек.. Дикость. Ну и соответственно ни один фреймворк/библиотека ничего норм не логируют. А потому что не понимают как..
- Библиотеки и фреймворки все как один плохо спроектированы. Возьмем нормальные платформы типа Java - есть либа для JSON (де)сериализации (например, Jackson), есть библиотека для валидации входящих данных (Bean Validation), есть для считывания свойств (Spring IoC). А в питоне? Там есть популярный Pydantic, который реализует все три штуки вместе! Как можно было придумать запихнуть три несвязанные друг с другом responsibilities в одну либу - в голову не приходит.
И ладно бы одна такая либа, но нет же.. SQLalchemy - это JOOQ и ORM в одном теле. При этом есть либа для миграции БД - и она зависит от SQLalchemy! Тут душа требует много восклицательных знаков. Ну вы представляете если бы Flyway зависил от JOOQ или Hibernate? И реально нет в питоне нормального инструмента по миграциям (я не нашел во всяком случае) - только недоделанный yoyo
- Отсутствие интерфейсов
- Нет строгого JDBC - есть только DB-API который кой-как описан. Но если хотите - можете не следовать (и есть много драйверов которые этого не делают!). Ну и соответственно нет универсальных DB Pool типа c3p0. Представляете - у постргреса в самом драйвере написан свой DB Pool 😵
Ой, я могу продолжать конечно, но надо бы и поработать 🙂
Forwarded from Phil
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
дак питон он для души в первую очередь
Forwarded from Филипп
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
Хорошо написал, согласен. Хочу уточнить про di в фастапи, что конкретно не устраивает?
Forwarded from Futorio Franklin
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
В общем один минус в том, что питон это не джава
Forwarded from Deleted Account
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
Скопировал)
Forwarded from Vitaliy
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
Если вы продолжите, будет замечательно. Без сарказма.
Forwarded from Sergey Ufocoder
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
Forwarded from Data Analysis / Big Data
Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google
Дайджест интересных статей о Python: что нового в версии 3.11, гайды по программированию на Python и обучающие статьи.
Читать: «Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google»
Дайджест интересных статей о Python: что нового в версии 3.11, гайды по программированию на Python и обучающие статьи.
Читать: «Дайджест Python: итоги 2022 года, обзор версии 3.11 и курсы от Google»
Forwarded from Big Data Science [RU]
🤔Почему библиотека NumPy так популярна в Python?
NumPy — это библиотека языка Python, которая добавляет поддержку больших многомерных массивов и матриц, а также высокоуровневых (и очень быстро выполняющихся) математических функций для операций с этими массивами. У данной библиотеки есть несколько важных особенностей, которые сделали ее популярным инструментом.
Во-первых, исходный ее код в свободном доступе хранится на GitHub, поэтому NumPy называют open-source модулем для Python. https://github.com/numpy/numpy/tree/main/numpy
Во-вторых, NumPy написана на языке C. Данный язык является компилируемым, то есть конструкции на этом языке преобразуются в машинный код — набор инструкций для конкретного типа процессора. Преобразование происходит с помощью специальной программы-компилятора, благодаря чему все вычисления происходят достаточно быстро.
Для примера сравним производительность NumPy-массивов и стандартных Python-списков:
import numpy
import time
list1 = range(1000000)
list2 = range(1000000)
array1 = numpy.arange(1000000)
array2 = numpy.arange(1000000)
initialTime = time.time()
resultantList = [(a * b) for a, b in zip(list1, list2)]
print("Время, затраченное на создание списка Python:",(time.time() - initialTime),"сек")
initialTime = time.time()
resultantArray = array1 * array2
print("Время, затраченное на создание массива NumPy :", (time.time() - initialTime),"сек")
Как результат, мы можем полагать, что NumPy-массивы показали себя намного быстрее (0.002 сек), чем стандартные Python-списки (0.11 сек)
В целом, можно сказать, что производительность NumPy различается на разных платформах из-за различий в программном и аппаратном обеспечении. В качестве примеров были протестированы генераторы псевдослучайных чисел. Подробности можно узнать на официальном сайте NumPy здесь: https://numpy.org/doc/stable/reference/random/performance.html#performance-on-different-operating-systems
NumPy — это библиотека языка Python, которая добавляет поддержку больших многомерных массивов и матриц, а также высокоуровневых (и очень быстро выполняющихся) математических функций для операций с этими массивами. У данной библиотеки есть несколько важных особенностей, которые сделали ее популярным инструментом.
Во-первых, исходный ее код в свободном доступе хранится на GitHub, поэтому NumPy называют open-source модулем для Python. https://github.com/numpy/numpy/tree/main/numpy
Во-вторых, NumPy написана на языке C. Данный язык является компилируемым, то есть конструкции на этом языке преобразуются в машинный код — набор инструкций для конкретного типа процессора. Преобразование происходит с помощью специальной программы-компилятора, благодаря чему все вычисления происходят достаточно быстро.
Для примера сравним производительность NumPy-массивов и стандартных Python-списков:
import numpy
import time
list1 = range(1000000)
list2 = range(1000000)
array1 = numpy.arange(1000000)
array2 = numpy.arange(1000000)
initialTime = time.time()
resultantList = [(a * b) for a, b in zip(list1, list2)]
print("Время, затраченное на создание списка Python:",(time.time() - initialTime),"сек")
initialTime = time.time()
resultantArray = array1 * array2
print("Время, затраченное на создание массива NumPy :", (time.time() - initialTime),"сек")
Как результат, мы можем полагать, что NumPy-массивы показали себя намного быстрее (0.002 сек), чем стандартные Python-списки (0.11 сек)
В целом, можно сказать, что производительность NumPy различается на разных платформах из-за различий в программном и аппаратном обеспечении. В качестве примеров были протестированы генераторы псевдослучайных чисел. Подробности можно узнать на официальном сайте NumPy здесь: https://numpy.org/doc/stable/reference/random/performance.html#performance-on-different-operating-systems
GitHub
numpy/numpy at main · numpy/numpy
The fundamental package for scientific computing with Python. - numpy/numpy
Бесплатный курс для всех, кто любит качественные IT-публикации и хочет научиться интересно писать о программировании либо улучшить навыки письма.
Курс состоит из семи модулей, посвященных написанию, редактированию, иллюстрированию и распространению публикаций. Ограничений на время прохождения заданий нет.
Курс будет интересен авторам, работающим в составе редакции, копирайтерам-одиночкам и просто программистам, которые хотят научиться интересно рассказывать о собственных проектах.
Материалы регулярно дополняются, обновляются и корректируется. Отвечаем на все учебные вопросы в комментариях курса.
Как стать автором «Библиотеки программиста» и получать гонорары за статьи?
➡️ Заполните анкету.
Если все ок, мы свяжемся с вами и обсудим дальнейшие шаги.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Библиотека дата-сайентиста | Data Science, Machine learning, анализ данных, машинное обучение
Хабр
Важные исследования в области AI в 2022 г
Данная статья представляет собой свободный перевод раздела "Исследования" из доклада State of the Art 2022 (октябрь). Доклад State of the Art публикуется уже пятый год. Это подборка самых интересных...
Forwarded from Библиотека дата-сайентиста | Data Science, Machine learning, анализ данных, машинное обучение
💰 Специалист по машинному обучению — востребованная и высокооплачиваемая профессия во всем мире. Если вы хотите попробовать себя в этой роли, приглашаем на первое знакомство с машинным обучением!
👉 25 января в 18:00 мск пройдет открытый урок «Первичный анализ данных с Pandas» в OTUS в рамках запуска специализации «Machine Learning».
💪 На занятии мы поговорим, как проводить первичный анализ данных в машинном обучении с использованием Python и обсудим, на что стоит ориентироваться при анализе данных, как обрабатывать признаки и как заполнять пропуски в данных.
👉 Чтобы участвовать зарегистрируйтесь https://otus.pw/3V1C7/
👉 25 января в 18:00 мск пройдет открытый урок «Первичный анализ данных с Pandas» в OTUS в рамках запуска специализации «Machine Learning».
💪 На занятии мы поговорим, как проводить первичный анализ данных в машинном обучении с использованием Python и обсудим, на что стоит ориентироваться при анализе данных, как обрабатывать признаки и как заполнять пропуски в данных.
👉 Чтобы участвовать зарегистрируйтесь https://otus.pw/3V1C7/
Понимание работы алгоритмов и умение применять их для решения прикладных задач — must-have для любого программиста или разработчика. Эта книга поможет вам не только развить навыки использования алгоритмов, но и разобраться в принципах их функционирования, в их логике и математике.
Вы начнете с введения в алгоритмы, от поиска и сортировки перейдете к линейному программированию, ранжированию страниц и графам и даже поработаете с алгоритмами машинного обучения. Теории не бывает без практики, поэтому вы займетесь прогнозами погоды, кластеризацией твитов, механизмами рекомендаций фильмов. И, наконец, освоите параллельную обработку, что даст вам возможность решать задачи, требующие большого объема вычислений.
Скидка 25% на все книги издательства Питер по промокоду
Proglib
🔗
ПодробнееPlease open Telegram to view this post
VIEW IN TELEGRAM
https://t.me/backend_megdu_skobkah/15832
через пару постов копипейст треда)
через пару постов копипейст треда)
Telegram
Stanislav Bashkyrtsev in { между скобок }
В понимании энтерпрайз/веб разработчика Dependency Injection - это фабрика, которая инициализирует объекты нашего приложения, проставляя им всем зависимости. Т.е. есть у нас какой-то Repository и Service. Сервису нужен объект Репозитория, но мы не хотим его…
Forwarded from Zen of Python
Список лучших библиотек на Python за 2022
В этот раз в подборку попало больше библиотек по ИИ и науке о данных, но всё равно в списке вы найдёте интересные ресурсы, которые стали популярны в этом году и не связаны с наукой:
https://habr.com/ru/post/707916/
#библиотека
В этот раз в подборку попало больше библиотек по ИИ и науке о данных, но всё равно в списке вы найдёте интересные ресурсы, которые стали популярны в этом году и не связаны с наукой:
https://habr.com/ru/post/707916/
#библиотека
Forwarded from Zen of Python
Вопросы и ответы к интервью для Python Developer
Годный репозиторий, в котором собраны популярные вопросы по Python и смежным темам: Django, ООП, принципы программирования, HTML, фронтенд и БД.
Сохраните, чтобы не потерять: https://github.com/yakimka/python_interview_questions
Годный репозиторий, в котором собраны популярные вопросы по Python и смежным темам: Django, ООП, принципы программирования, HTML, фронтенд и БД.
Сохраните, чтобы не потерять: https://github.com/yakimka/python_interview_questions
Forwarded from Stanislav Bashkyrtsev
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место.
- Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а тот не хочу". Все что есть в репозитории модулей (site-packages) доступно, ну и соответственно нет возможности несколько версий одной библиотеки иметь (для разных приложений). За сим имеем кучу инструментов (pyenv, venv, virtualenv, etc) которые "решают" эту проблему страшными хаками типа "а давайте для этого проекта создадим его виртуальное окружение с его копией питона, файлами которые переопределяют стандартные питон модули, и так изолируем его зависимости"
- Инструменты сборки постоянно меняются, существует несколько инструментов по скачиванию зависимостей. И представляете - опубликованную версию зависимости можно удалить из центральной репы! У меня такое было лет 10 назад с mysql драйвером. Вот это я удивился..
- Нет ничего на подобие Spring IoC + Spring MVC. Т.е. нет возможности написать веб приложение с Dependency Injection'ом. Я счас просто свой IoC сделал в проекте. Что в целом не мешает, однако он же никак с MVC не интегрируются. Вроде как FastAPI обещал сделать Dependency Injection, а на самом деле сделал вообще не его. Но при этом сказал что это DI 😵 Т.е. вы не можете описать любые singleton бины и их заинжектить - он просто дергает метод, который каждый раз создает новые объекты (и вроде все равно не каждый объект можно так создать).
- Логирование.. казалось бы что может тут пойти не так. Но пришлось 2 дня разбираться как его настроить. 99% примеров в интернетах создают свою глобальную функцию по созданию логера, чтоб его централизованно так настраивать. Это вместо того чтоб использовать файл настроек.. Дикость. Ну и соответственно ни один фреймворк/библиотека ничего норм не логируют. А потому что не понимают как..
- Библиотеки и фреймворки все как один плохо спроектированы. Возьмем нормальные платформы типа Java - есть либа для JSON (де)сериализации (например, Jackson), есть библиотека для валидации входящих данных (Bean Validation), есть для считывания свойств (Spring IoC). А в питоне? Там есть популярный Pydantic, который реализует все три штуки вместе! Как можно было придумать запихнуть три несвязанные друг с другом responsibilities в одну либу - в голову не приходит.
И ладно бы одна такая либа, но нет же.. SQLalchemy - это JOOQ и ORM в одном теле. При этом есть либа для миграции БД - и она зависит от SQLalchemy! Тут душа требует много восклицательных знаков. Ну вы представляете если бы Flyway зависил от JOOQ или Hibernate? И реально нет в питоне нормального инструмента по миграциям (я не нашел во всяком случае) - только недоделанный yoyo
- Отсутствие интерфейсов
- Нет строгого JDBC - есть только DB-API который кой-как описан. Но если хотите - можете не следовать (и есть много драйверов которые этого не делают!). Ну и соответственно нет универсальных DB Pool типа c3p0. Представляете - у постргреса в самом драйвере написан свой DB Pool 😵
Ой, я могу продолжать конечно, но надо бы и поработать 🙂
- Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а тот не хочу". Все что есть в репозитории модулей (site-packages) доступно, ну и соответственно нет возможности несколько версий одной библиотеки иметь (для разных приложений). За сим имеем кучу инструментов (pyenv, venv, virtualenv, etc) которые "решают" эту проблему страшными хаками типа "а давайте для этого проекта создадим его виртуальное окружение с его копией питона, файлами которые переопределяют стандартные питон модули, и так изолируем его зависимости"
- Инструменты сборки постоянно меняются, существует несколько инструментов по скачиванию зависимостей. И представляете - опубликованную версию зависимости можно удалить из центральной репы! У меня такое было лет 10 назад с mysql драйвером. Вот это я удивился..
- Нет ничего на подобие Spring IoC + Spring MVC. Т.е. нет возможности написать веб приложение с Dependency Injection'ом. Я счас просто свой IoC сделал в проекте. Что в целом не мешает, однако он же никак с MVC не интегрируются. Вроде как FastAPI обещал сделать Dependency Injection, а на самом деле сделал вообще не его. Но при этом сказал что это DI 😵 Т.е. вы не можете описать любые singleton бины и их заинжектить - он просто дергает метод, который каждый раз создает новые объекты (и вроде все равно не каждый объект можно так создать).
- Логирование.. казалось бы что может тут пойти не так. Но пришлось 2 дня разбираться как его настроить. 99% примеров в интернетах создают свою глобальную функцию по созданию логера, чтоб его централизованно так настраивать. Это вместо того чтоб использовать файл настроек.. Дикость. Ну и соответственно ни один фреймворк/библиотека ничего норм не логируют. А потому что не понимают как..
- Библиотеки и фреймворки все как один плохо спроектированы. Возьмем нормальные платформы типа Java - есть либа для JSON (де)сериализации (например, Jackson), есть библиотека для валидации входящих данных (Bean Validation), есть для считывания свойств (Spring IoC). А в питоне? Там есть популярный Pydantic, который реализует все три штуки вместе! Как можно было придумать запихнуть три несвязанные друг с другом responsibilities в одну либу - в голову не приходит.
И ладно бы одна такая либа, но нет же.. SQLalchemy - это JOOQ и ORM в одном теле. При этом есть либа для миграции БД - и она зависит от SQLalchemy! Тут душа требует много восклицательных знаков. Ну вы представляете если бы Flyway зависил от JOOQ или Hibernate? И реально нет в питоне нормального инструмента по миграциям (я не нашел во всяком случае) - только недоделанный yoyo
- Отсутствие интерфейсов
- Нет строгого JDBC - есть только DB-API который кой-как описан. Но если хотите - можете не следовать (и есть много драйверов которые этого не делают!). Ну и соответственно нет универсальных DB Pool типа c3p0. Представляете - у постргреса в самом драйвере написан свой DB Pool 😵
Ой, я могу продолжать конечно, но надо бы и поработать 🙂
Forwarded from Филипп
#python python... PYTHON 🔛 🚀
Проблема питона - не скорость.. Со скоростью в большинстве сервисов можно смириться. Проблема в том что все плохо продумано, коммьюнити очень слабое - все инструменты через одно место. - Система загрузки модулей.. Не позволяет сказать "хочу этот модуль, а…
Хорошо написал, согласен. Хочу уточнить про di в фастапи, что конкретно не устраивает?
Forwarded from Stanislav Bashkyrtsev
#python python... PYTHON 🔛 🚀
Хорошо написал, согласен. Хочу уточнить про di в фастапи, что конкретно не устраивает?
В понимании энтерпрайз/веб разработчика Dependency Injection - это фабрика, которая инициализирует объекты нашего приложения, проставляя им всем зависимости. Т.е. есть у нас какой-то Repository и Service. Сервису нужен объект Репозитория, но мы не хотим его создавать прям внутри Сервиса. Потому как а) для создания Репозитория нужны свои зависимости (DataSource, JdbcTemplate, etc) и б) этот же репозиторий нужен будет еще каким-то Сервисам. Поэтому мы создаем один Репозиторий на все приложение (это делает наша Фабрика), и пропихивает его всем Сервисам и кому там еще он нужен. Всё - все объекты проинициализированы и весь код готов к работе.
В FastAPI то что они называют Dependency Injection - эт совсем другое. Это просто функция, которую сам FastAPI вызовет прежде чем вызывать метод API. И вернувшееся значение будет передано уже в целевой метод API:
Т.е. это было бы аналогично такому коду:
И это они назвали Dependency Injection.. И у них есть набор пред-определенных объектов которые они сами могут таким же механизмом пробросить в метод. Например, ту же Session из SQLalchemy 🤦
В общем относительно бесполезный механизм. А DI как не было, так и нет - значит все Сервисы/Репозитории/DataSource'ы нужно инициализировать какими-то синглтонами/фабриками.
В FastAPI то что они называют Dependency Injection - эт совсем другое. Это просто функция, которую сам FastAPI вызовет прежде чем вызывать метод API. И вернувшееся значение будет передано уже в целевой метод API:
def create_dog_from_params(self, some_http_param):
return Dog.from_http(some_http_param)
@router.put(path="/dog")
def get_dog(dog=Depends(create_dog_from_params)):
dog_service.save(dog)
Т.е. это было бы аналогично такому коду:
@router.put(path="/dog")
def get_dog(some_http_param):
dog = create_dog_from_params(some_http_param)
dog_service.save(dog)
И это они назвали Dependency Injection.. И у них есть набор пред-определенных объектов которые они сами могут таким же механизмом пробросить в метод. Например, ту же Session из SQLalchemy 🤦
В общем относительно бесполезный механизм. А DI как не было, так и нет - значит все Сервисы/Репозитории/DataSource'ы нужно инициализировать какими-то синглтонами/фабриками.