Как скомпилировать Python

Да вы правы. Cython уже умеет компилировать python на прямую! А я похоже это проспал. Это здорово — больше python-компиляторов богу python-компиляторов. Добавлю в статью.

Как скомпилировать Python

Да, я слышал об этом, но это пока в планах. Но мне казалось, что они хотят просто сделать cython более похожим на python, но не компилировать сам python. В любом случае сейчас это не работает.

Как скомпилировать Python

В том смысле, что не получится просто взять и скомпилировать, приведенную выше, функцию bubble_sort с помощью Сython. Ее нужно сначала переписать на Сython, а потом можно будет скомпилировать в С. А с помощью mypyc можно скомпилировать прямо python код. Т.е. один и тот же исходник может работать как обычный python модуль, так и в форме бинарника (CPython Extension).

Как скомпилировать Python

Cython — хороший инструмент, но он не умеет «компилировать питонячий код». Cython это отдельный язык, местами похожий на python, и только.

Принципиально новый метод позволяет тренировать ИИ практически без данных

Посмотрел бы я на обучение ребенка по картинкам из примера. Ведь именно эта аналогия описана в начале статьи

Асинхронный Python-код медленнее обычного кода

> В данном конкретном случае, по сути, измеряется производительность базы данных

Почему тогда одна и та же БД с синхронным фронтендом работает быстрее?

Нейросеть — обучение без учителя. Метод Policy Gradient

Интересный будет цикл. Жду продолжения

Clean Architecture глазами Python-разработчика

Если посмотреть пример, то там используются не нативные датаклассы, а pydantic, и в от личии от attrs они обеспечивают валидацию входных данных, сериализацию, и генерацию схемы для openapi. Must have pydantic-docs.helpmanual.io

Clean Architecture глазами Python-разработчика

Дорогой @profit404, я даже добавил ссылку на dry-python в конце статьи, но почему же Вы выкатили свои ссылки, не добавив столь нибудь существенного комментария по тексту статьи (

Clean Architecture глазами Python-разработчика

На самом деле, один из основных посылов, который я бы хотел донести, что сейчас python позволяет реализовать данную модель без особого оверворка, да, результат получился больше чем могло бы быть решение в лоб, но совершенно минимально, зато теперь определен вектор дальнейшего развития, во что бы он в конечном счете не превратился

Clean Architecture глазами Python-разработчика

> нужно просто нафигачить sql в контроллере и не парится

Совершенно верно, пример (не мой) совершенно гротескный, зато в нем хорошо видно тот минимальный оверворк, который несет предложенный подход, посмотрите еще раз он совершенно не большой.

> Что должно измениться в проекте, чтобы sql в контроллере перестал быть самым простым и понятным решением?

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

> всегда добавляет уйму ненужного кода

Основную массу ненужного кода составляет маппинг структур которые движутся между слоями, такие библиотеки как pydantic, позволяют его минимизировать.
Ну а отсутствие необходимых примитивов и одновременное накачивание проекта быстрыми фичами могут превратить весь проект — в «уйму ненужного кода»

Clean Architecture глазами Python-разработчика

> Она начинает работать только с какого-то определенного объёма проекта или как?

И да и нет, в общем случае действительно можно констатировать, что актуальность проблемы снижается в эру микросервисов. Программист физически не может импортнуть в свой микросервис модуль из другого микросервиса. Тем самым установив между ними связь в обход API.
Другой момент, что многие микросервисы несут утилитарный характер и содержат минимум бизнес-логики, во некоторых моих сервисах, services занимает около 10% от общего объема кода.
Но, даже в таком случае я вижу все преимущества о которых говорится в статье, к тому же, микросервисы также имеют свойство расширяться, и стало быть применение Сlean Archetecture это задел на будущее.
Еще один бонус — в микросервисной архитектуре сервисы в основном взаимодействуют друг с другом посредством обращения к их АПИ, и это очень хорошо вписывается в предложенную модель, если ORM нас как-то абстрагируют от БД, то обвязки API придется писать самим.

Ну а самое главное: если начинать с модели описанной в статье то оверворк будет совсем небольшим, и сполна перекрывается плюсами.

Clean Architecture глазами Python-разработчика

Да, именно, entity — выделяются из services, по мере необходимости, но начинаю проект именно с такой простой структуры

Clean Architecture глазами Python-разработчика

В простом случае будет практически тоже самое, что в примере github.com/zueve/rentomatic:

project/
   services/
   adapters/
   rest/

причем если следовать заветам, то содержимое services можно прямо в корень project кидать — ибо «приложение должно кричать»

Clean Architecture глазами Python-разработчика

Точно! Спасибо поправил