Тут даже не обязательно вводить отдельную формулу размещений с повторениями. Эта задача решается простой логикой из раздела "Правило произведения" (союз И), который я описал в начале статьи: У нас 4 независимых выбора по 10 вариантов в каждом. Перемножаем их
Действительно какой смысл в обучающих статья? Сам задаюсь этим вопросом, зачем создавать статьи, в которых объясняется какая то важная тема... Я обязательно подумаю)
Здравствуйте, Какие артефакты? У вас претензии именно из за того что статья некачественная или что? Если есть какие то ошибки в статье или не точности, я готов их обсуждать и редактировать статью)
Текст действительно "причесывался" инструментами, чтобы убрать воду и ошибки — это уважение к читателю. Но архитектура, код и подход к разделению слоев — это мой опыт, а не галлюцинации нейросети.Если видите технические ошибки или анти-паттерны в коде — давайте обсуждать их предметно. Я здесь ради этого.
Спасибо за комментарий, вопрос отличный и закономерный.
Действительно, Django — прекрасный "батарейный" фреймворк, где многие решения приняты за разработчика. Если задача — быстро поднять стандартную админку и CRUD, Django часто выигрывает.
Однако я не соглашусь с тезисом, что FastAPI — только для маленьких проектов. Структура, которую я описываю, — это не попытка "написать свой фреймворк", а реализация классической Clean Architecture / Layered Architecture. Мы не изобретаем велосипед, а используем принцип Composition over Inheritance (композиция вместо наследования), который лежит в основе FastAPI.
Почему не Django?
Асинхронность: FastAPI изначально спроектирован под async/await и высокий I/O. Django async догоняет, но тащит огромный синхронный хвост.
Типизация: Связка Pydantic + FastAPI дает строгую валидацию и автодокументацию на уровне типов Python. В Django работа с типами часто менее прозрачна (магия ORM).
SQLAlchemy 2.0: Она дает гораздо больше контроля над SQL-запросами, чем Django ORM, что критично на высоких нагрузках.
Выбор между ними — это выбор между "Convention over Configuration" (Django) и "Explicit is better than implicit" (FastAPI). Эта статья для тех, кто выбрал второй путь и хочет пройти его правильно».
вы абсолютно правы! Пытаться прогнать ETL-пайплайн на миллион записей через Pydantic (или любые Python-объекты в цикле) — это очень плохо. Для таких объемов есть векторные вычисления в Polars/Pandas.
Но у Pydantic другая ниша: это транзакционная логика. Когда к нам прилетает один сложный JSON-запрос на создание заказа со вложенными адресами и списками товаров, нам не нужен DataFrame. Нам нужен строгий валидированный объект, с которым удобно работать в бизнес-логике.
Pydantic — для API и конфигов. Polars — для "молотилок" данных. Инструменты разные, и задачи у них разные.
Про неявный кастинг: Тут вопрос философии. Когда мы принимаем данные из JSON или query-параметров (где всё — строки), автоматическое приведение типов спасает от написания тонн бойлерплейта. Но если нужна строгость — в Pydantic V2 есть ConfigDict(strict=True), который будет кидать ошибки, как вы и описали.
Про производительность: Вы, вероятно, вспоминаете Pydantic V1. Вторая версия (о которой статья) написана на Rust и в синтетических тестах приблизилась к msgspec (хотя msgspec всё еще быстрее, тут спорить глупо).
1. Спасибо за историческую справку по версии 2.3. Действительно, модуль появился тогда, но с тех пор язык эволюционировал, и в Python 3 концепция итераторов стала фундаментальной (PEP 234).
2. Про TCO: Пожалуйста, поделитесь ссылкой на PEP или release notes CPython, где добавили нативную поддержку TCO. Насколько известно официальной документации и BDFL, в Python оптимизации хвостовой рекурсии нет, и глубокая рекурсия вызывает переполнение стека. Итераторы — единственный безопасный способ обработки больших данных.
Спасибо за внимательность! Вы абсолютно правы насчет разницы алгоритмов.
Пример во введении я привел как самую узнаваемую визуализацию анти-паттерна "Arrowhead" (бесконечные отступы вправо), который знаком всем. А itertools.product привел первым пунктом как самый простой способ избавиться от вложенности в комбинаторных задачах, так как они нагляднее для старта.
Согласен, что переход получился резким. Задачу из введения по-хорошему нужно решать через генераторы или itertools.chain.from_iterable, "выпрямляя" списки команд и сотрудников. Рад, что статью читают вдумчиво, учту этот момент в будущих материалах!
Спасибо за развернутый комментарий! Чувствуется, что вы уже плотно работаете с Poetry 2.0 и новыми стандартами.
Однако цель статьи — помочь новичкам, которые прямо сейчас сидят на requirements.txt и pip, перейти на более удобный инструмент. Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry] (версии 1.x), и именно с ним читатель столкнется в 99% случаев. Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.
По пунктам:
Lock-файл: Для конечных приложений (а статья ориентирована на них, боты/сайты) комитить лок — это best practice. Для библиотек — да, не стоит, но это отдельная тема.
OS: Лок-файл решает проблему версий пакетов. Проблему бинарных сборок под разные архитектуры решает Docker (о чем и сказано в конце).
Python 3.11: Это актуальный LTS релиз, на котором крутится огромная часть продакшена.
Ваше дополнение про Poetry 2.0 очень ценное, оно показывает вектор развития инструмента. Спасибо!
Звучит как суровое, но справедливое код-ревью времен моей стажировки в команде АБТ :) (zaplavs)
Вы абсолютно правы насчет архитектуры серьезных проектов (разделение логики, View и т.д.). Но если я сейчас вывалю на новичка паттерны проектирования, он просто закроет вкладку. Здесь мы намеренно упрощаем (KISS), чтобы человек понял суть self и полиморфизма. А до "серьезной архитектуры" мы с читателями дорастем в следующих статьях!
Вы приводите примеры сложных систем (Heroes, Wesnoth), а мы здесь разбираем алфавит. Конечно, архитектура AAA-стратегии строится иначе (ECS, Event Bus и т.д.). Но нельзя научить человека писать «Войну и мир», пока он не выучил буквы. Этот код — демонстрация базовых принципов (Наследование/Полиморфизм) в вакууме, а не готовый движок для Steam.
Плохой рекламы не бывает) Спасибо за упоминания!
Вы абсолютно правы про 10 000 вариантов!
Тут даже не обязательно вводить отдельную формулу размещений с повторениями. Эта задача решается простой логикой из раздела "Правило произведения" (союз И), который я описал в начале статьи:
У нас 4 независимых выбора по 10 вариантов в каждом. Перемножаем их
и получаем те самые 10 000.
Зачем мне ставить минус за критику, которая приводит хоть какие то Аргументы? А не просто кричит фу это нейросеть...
Ну так в статье объясняется почему в файлике по другому работает) Прочитай те статью пожалуйста полностью)
А вы запускали через cmd? или в файлике?
Спасибо за ваше развернутое мнение. С вами я полностью согласен.
Действительно какой смысл в обучающих статья? Сам задаюсь этим вопросом, зачем создавать статьи, в которых объясняется какая то важная тема... Я обязательно подумаю)
Здравствуйте, Какие артефакты? У вас претензии именно из за того что статья некачественная или что? Если есть какие то ошибки в статье или не точности, я готов их обсуждать и редактировать статью)
Мимо)
Спасибо за объективное мнение)
А вы можете сказать, что именно в этой статье некачественное, чтобы в будущих статьях я не допускал таких ошибок, заранее благодарен)
Текст действительно "причесывался" инструментами, чтобы убрать воду и ошибки — это уважение к читателю. Но архитектура, код и подход к разделению слоев — это мой опыт, а не галлюцинации нейросети.Если видите технические ошибки или анти-паттерны в коде — давайте обсуждать их предметно. Я здесь ради этого.
Спасибо за комментарий, вопрос отличный и закономерный.
Действительно, Django — прекрасный "батарейный" фреймворк, где многие решения приняты за разработчика. Если задача — быстро поднять стандартную админку и CRUD, Django часто выигрывает.
Однако я не соглашусь с тезисом, что FastAPI — только для маленьких проектов. Структура, которую я описываю, — это не попытка "написать свой фреймворк", а реализация классической Clean Architecture / Layered Architecture.
Мы не изобретаем велосипед, а используем принцип Composition over Inheritance (композиция вместо наследования), который лежит в основе FastAPI.
Почему не Django?
Асинхронность: FastAPI изначально спроектирован под async/await и высокий I/O. Django async догоняет, но тащит огромный синхронный хвост.
Типизация: Связка Pydantic + FastAPI дает строгую валидацию и автодокументацию на уровне типов Python. В Django работа с типами часто менее прозрачна (магия ORM).
SQLAlchemy 2.0: Она дает гораздо больше контроля над SQL-запросами, чем Django ORM, что критично на высоких нагрузках.
Выбор между ними — это выбор между "Convention over Configuration" (Django) и "Explicit is better than implicit" (FastAPI). Эта статья для тех, кто выбрал второй путь и хочет пройти его правильно».
вы абсолютно правы! Пытаться прогнать ETL-пайплайн на миллион записей через Pydantic (или любые Python-объекты в цикле) — это очень плохо. Для таких объемов есть векторные вычисления в Polars/Pandas.
Но у Pydantic другая ниша: это транзакционная логика. Когда к нам прилетает один сложный JSON-запрос на создание заказа со вложенными адресами и списками товаров, нам не нужен DataFrame. Нам нужен строгий валидированный объект, с которым удобно работать в бизнес-логике.
Pydantic — для API и конфигов. Polars — для "молотилок" данных. Инструменты разные, и задачи у них разные.
Спасибо за альтернативное мнение!
Про неявный кастинг: Тут вопрос философии. Когда мы принимаем данные из JSON или query-параметров (где всё — строки), автоматическое приведение типов спасает от написания тонн бойлерплейта. Но если нужна строгость — в Pydantic V2 есть ConfigDict(strict=True), который будет кидать ошибки, как вы и описали.
Про производительность: Вы, вероятно, вспоминаете Pydantic V1. Вторая версия (о которой статья) написана на Rust и в синтетических тестах приблизилась к msgspec (хотя msgspec всё еще быстрее, тут спорить глупо).
1. Спасибо за историческую справку по версии 2.3. Действительно, модуль появился тогда, но с тех пор язык эволюционировал, и в Python 3 концепция итераторов стала фундаментальной (PEP 234).
2. Про TCO: Пожалуйста, поделитесь ссылкой на PEP или release notes CPython, где добавили нативную поддержку TCO. Насколько известно официальной документации и BDFL, в Python оптимизации хвостовой рекурсии нет, и глубокая рекурсия вызывает переполнение стека. Итераторы — единственный безопасный способ обработки больших данных.
Спасибо за внимательность! Вы абсолютно правы насчет разницы алгоритмов.
Пример во введении я привел как самую узнаваемую визуализацию анти-паттерна "Arrowhead" (бесконечные отступы вправо), который знаком всем. А itertools.product привел первым пунктом как самый простой способ избавиться от вложенности в комбинаторных задачах, так как они нагляднее для старта.
Согласен, что переход получился резким. Задачу из введения по-хорошему нужно решать через генераторы или itertools.chain.from_iterable, "выпрямляя" списки команд и сотрудников. Рад, что статью читают вдумчиво, учту этот момент в будущих материалах!
Спасибо за развернутый комментарий! Чувствуется, что вы уже плотно работаете с Poetry 2.0 и новыми стандартами.
Однако цель статьи — помочь новичкам, которые прямо сейчас сидят на requirements.txt и pip, перейти на более удобный инструмент. Подавляющее большинство проектов и туториалов в сети всё ещё используют синтаксис [tool.poetry] (версии 1.x), и именно с ним читатель столкнется в 99% случаев. Грузить их сразу PEP 621 и миграцией на 2.0 — значит отпугнуть сложностью.
По пунктам:
Lock-файл: Для конечных приложений (а статья ориентирована на них, боты/сайты) комитить лок — это best practice. Для библиотек — да, не стоит, но это отдельная тема.
OS: Лок-файл решает проблему версий пакетов. Проблему бинарных сборок под разные архитектуры решает Docker (о чем и сказано в конце).
Python 3.11: Это актуальный LTS релиз, на котором крутится огромная часть продакшена.
Ваше дополнение про Poetry 2.0 очень ценное, оно показывает вектор развития инструмента. Спасибо!
Звучит как суровое, но справедливое код-ревью времен моей стажировки в команде АБТ :) (zaplavs)
Вы абсолютно правы насчет архитектуры серьезных проектов (разделение логики, View и т.д.). Но если я сейчас вывалю на новичка паттерны проектирования, он просто закроет вкладку. Здесь мы намеренно упрощаем (KISS), чтобы человек понял суть self и полиморфизма. А до "серьезной архитектуры" мы с читателями дорастем в следующих статьях!
Вы приводите примеры сложных систем (Heroes, Wesnoth), а мы здесь разбираем алфавит. Конечно, архитектура AAA-стратегии строится иначе (ECS, Event Bus и т.д.). Но нельзя научить человека писать «Войну и мир», пока он не выучил буквы. Этот код — демонстрация базовых принципов (Наследование/Полиморфизм) в вакууме, а не готовый движок для Steam.