Комментарии 40
Из всех подробных, что видел, это самый!!! Спасибо за столь титаническую работу!
"Отличная" идея, кстати, для декоратора. Пишем пустой метод, документирующий комментарий и декоратор @chatgtpсам там что-нибудь пишет в тело метода... :-D
Спасибо за поддержку.
Увидел название и первая мысль - таакк, скорее всего будет асинхронный FastAPI и синхронный вызов Celery внутри. Хотелось ошибиться - специально зашёл проверить.
Но нет. Функция объявлена как async, но обращение к Redis (и не одно!) синхронное, вызов send_task тоже синхронный.. И вообще ни одного await внутри функции. Возьмите уж тогда обычный Flask.
Да, стандартного способа вызвать таску celery из асинхронного кода нет. Для этого всем приходится слегка реверсить код celery и для каждого брокера писать свой асинхронный менеджер чтобы запустить таску или получить результаты.
Плохому учите, гражданин.
То что отдельные методы не оптимальны - это уже вопрос оптимизации. Статья явно для начального или среднего уровня, чтобы погрузиться в тему. Общее понимание архитектуры после прочтения у меня, например, появилось. В комментариях часто нахожу то, что пропускает чатгпт:) Так что благодарю автора, и комментаторов.
Спасибо за поддержку.
Отнюдь. Я пропустил остальные замечания где можно что-то улучшить или дополнить, как раз потому что это не так важно для начального или среднего уровня.
Однако, вызов синхронного кода из асинхронной функции - это грубая ошибка. Сейчас этот код кто-то возьмёт и потащит ставить на рабочий проект, а потом будет удивляться тому, что он не справляется с обычной нагрузкой.
В статье рассматривается именно интеграция FastAPI и Celery и именно это сделано неправильно.
Дайте хороший и качественный код. Покажите как нужно. Правда. Зачем писать простыни текста если можно скинуть правильный код. Тут же речь про пару строк. Я думаю, что не только мне это интересно будет.
Ну, вообще говоря, я приводил код, 1.5 года назад, в комментариях к другой статье. Я выдирал его из рабочего проекта, убирая кучу деталей, так что он просто показывает куда нужно думать. Написать статью по этой теме - наверное хорошая идея, но у меня на это времени нет совсем.
except Exception as e:
Мдо-о-о... No comments.
Правильно, мне нужно было в учебной статье написать 50 обработчиков всевозможных ошибок, чтоб у вас были "comments")
Сильно лучше чем except:
Это был сарказм?except == `except [Exception [as e]]`
PS. у нас в деревне был случай.
Долго не мог понять почему работодатель обрывает микросервисы в докере путем убиения образов.
Потому что просто так микросервисы не остановить.
Ctrl-C внезапно тоже exception.
Которое перехватывается except: 'ом, ога
Не знаю в курсе ли вы, но в конструкции except Exception as e последняя "e" указывает на ошибку. То есть вы бы в своей деревне смогли посмотреть логи и увидеть в чем ошибка. Берите на заметку. Не всегда нужно писать обработчики под всевозможные ошибки.
Несмотря на то, что Вы яростно минусуете, я таки рискну еще раз прокомментировать:
1. `except Exception as e` - это прелестно, но вслед за этим `return None` - это совсем не прелестно. Куда return, почему None - непонятно. Лезть вверх по стеку вызовов занятие так себе.
2. Вызов лога может вызвать exception. Который мы перехватываем. Р - Рекурсия.
3. "Не всегда нужно писать обработчики под всевозможные ошибки" - у Вас в коде таки обработчики под все возможные ошибки. Точнее не ошибки, а прерывания. И не обработчики, а заглушки. Без выхода.
4. Читайте PEP. Номер не помню, но точно помню - писать except: нельзя. То есть технически можно, но практически не надо так делать.
5. Таки да, собирайте все возможные exceptions, и обрабатывайте их индивидуально. Деление на 0 и ошибки в синтаксисе в том числе. Если что-то забыли, то приложение должно падать, а не вертать None.
6. Хорошая новость: если по таким учебным материалам делается большинство проектов, то работа будет всегда. За это - спасибо.
6.1. И это правда... Я получил X (если не Y) денег за переработку "микросервисов", вынув из них это вот `except Exception as e`. Месяц работы. Но потом оно хотя бы перестало зависать.
Справедливости ради, если в демо-проекте разворачивать весь перехват ошибок тоже - то тут еще страниц 10 написать можно. Статья - про FastAPI и вызов Celery (который как раз сделан неправильно).
В обработчике (даже except:) можно написать logger.exception("Error here") и всё будет хорошо - поскольку используется loguru, то в лог попадёт детальный стектрейс и даже значения переменных, так что ошибку вы увидите. В продакшене, конечно, так не надо делать и надо ловить исключения через FastAPI: app.exception_handler
К демо претензий нет, отличное.
Но впихивать в учебный (это же кого-то чему-то учит?) проект такие фееричные конструкции - перебор. Что можешь - обработай, что не можешь - не трогай.
Вы представляете вообше какое там количество всевозможных исключений есть? Ну ок. Я неправильно записал. Какие бы лично вы исключения там обработали? Можно список?
Простите, снова я вставлю своё мнение (никто не просил, да).
Можно вообще его не перехватывать здесь, а дать функции упасть. Тогда FastAPI сгенерирует HTTP 500 - фактически, это оно и есть.
Чтобы не показывать пользователю стектрейс, можно использовать exception_handler .
@yakvenalexПрислушайтесь к рекомендациям @baldr.
Хотя он просто "Пользователь", а не "Опытный разработчик Python etc.". Скорее всего он не просто Пользователь, а уже знает токсичность habr.
Принцип очень простой (как в ПДД): "Не видим - не едем".
1. Обрабатываете только те exceptions, которые надо обработать именно в этом месте
2. Всё остальное падает и улетает наверх
3. Наверху (в абстрактном `main.py`) можете работать как хотите
4. но писать `except Exception` писать нельзя никогда нигде и ни в коем случае. Читайте PEP
5. И хватит уже минусовать всех подряд куда попало, Вам это здоровья не прибавит
Я подозреваю, что некое @baldrумеет в питон и иже лучше Вас, меня и еще роту таких же.
Просто ему/ей понравилось Ваша статья.
Мне тоже понравилась, честно говоря. Просто надо очистить от "плохому учить". Я так думаю.
Ну это относительно все. Возможно в этой теме и лучше чем я, но опять таки. Вы тут обрушились мол вот плохому учите, а я и в статье писал что упрощаю намеренно. Получается, что на это глаза закрываем, на то что было сказано прямо и дальше начинаем оценивать меня, как программиста, верно?
Еще раз уточню - статья просто роскошная. Я сохранил себе в закладки и буду учиться по ней.
НО: "що занадто - то не здраво".
Если бы Вы вообще не обрабатывали exceptions - слова бы никто не сказал. Ну или кто-нить помурчал че-нить, но недолго.
1. Никто ж ни слова не сказал про docstrings и русский в комментариях; хотя это поперек PEP.
2. Об аннотациях (точнее отсутствии) и слова никто не вякнул; хотя в этом сезоне такое моветон.
И т.д. и т.п. На нет и суда нет.
Но `except Exception...` - это перебор.
Вот. Давайте начнем меряться кол-вом переписанных за кем-то проектов)
Вы будете смеяться. Но разница в поведении есть. except: перехватывает BaseException. Который помимо Exception ещё включает такие вещи как KeyboardInterrupt и не только. Во есть можно написать код, который нельзя остановить с клавиатуры вообще.
Каюсь, не помню напамять иерархию exceptions. Тогда да, `exception Exception ... :` лучше `exception:`
Тем не менее мне пришлось рихтовать проект с пачкой `exception Exception`, потому что остановить контейнер с этим поделием штатными средствами не удавалось. Ну и вешалось периодически (потому что в подлежащих библиотеках свои заморочки).
Так я только 1 диз поставил вам, а тут ещё сверху их куча)
Ребята, серьезно? Дизлайкать за "спасибо за поддержку"? Что у вас в голове вообще? Давайте по порядку.
Про GPT и "всё готово за 5 минут":
Если вы думаете, что можно сделать подобный проект и написать статью такого уровня, просто прокинув запрос в нейросеть — попробуйте. Вот реально, садитесь и сделайте. Но предупреждаю, на это уйдёт не 5 минут, а несколько полных дней работы. Код, идеи, текст — это всё моё. GPT я использую исключительно как инструмент для вычитки и доработки отдельных блоков. Это нормальная практика, и нет ничего плохого в том, чтобы использовать инструменты, которые помогают улучшать результат.Про "вечный хейт":
Давайте не будем лицемерить. Делать что-то своими руками, тратить своё время, силы и потом получать вместо нормальной поддержки дизлайки за благодарность — это смешно. Если вам не нравится то, что я делаю, — окей, ваше право. Но неужели вам обязательно тратить свою энергию, чтобы писать или кликать негатив? Если у вас есть конструктив, говорите. Если нет — зачем вообще заходить в эту тему?Про поддержку:
Когда кто-то выражает поддержку — я благодарю. Это нормально. Это человеческое. И если даже это вызывает у кого-то желание поставить дизлайк, то, честно говоря, вопрос уже не ко мне, а к вашему внутреннему состоянию.
Мои проекты и статьи — это труд, а не кнопка "Сгенерировать" в нейросети. Хотите критиковать — сначала покажите, что вы сами можете сделать лучше. А если нечего показать — задумайтесь, что вообще побуждает вас тратить время на негатив.
Я понимаю ваше возмущение, но могу только посоветовать привыкнуть - к любой статье будут коментарии. Нет комментариев только к статье, которую не читали.
Вам указывают на недостатки - они есть. Они есть всегда. Перехват Exception - действительно, не критично. Использовать Redis в качестве брокера - ок, в учебном проекте можно. Я лично написал о том что считаю реально большой ошибкой.
Ребята, серьезно? Дизлайкать за "спасибо за поддержку"? Что у вас в голове вообще?
Добро пожаловать на Хабр. Пустые комментарии "спасибо" здесь не очень ценятся - для этого можно стрелочку нажать. (я не ставил этот дизлайк если что)
К ChatGPT лично у меня особо нет возражений, если в статье написана интересная тема.
Принято, но предполагаю что дело не в "пустом комментарии". Что касается кода. Я всегда позитивно отношусь к конструктивной критике и лично к вам вообще вопросов никаких нет, разве что я бы хотел увидеть более корректную реализацию именно в коде.
Добро пожаловать на Хабр. Пустые комментарии "спасибо" здесь не очень ценятся - для этого можно стрелочку нажать. (я не ставил этот дизлайк если что)
для этого можно стрелочку нажать
К сожалению, это не всем доступно :(
Спасибо за такую подробную и интересную статью. Оказалась очень полезной. FastAPI + Redis вообще очень популярна сейчас.
А насчёт хейтеров: не переживай и не бери близко к сердцу - их везде хватает. Даже не обязательно лютых хейтеров, а просто грубых и необразованных людей.
Продолжай писать подобные интересные статьи.
В качестве бесплатного локального s3 можно добавить в связку minio
У меня уже глаз дергается от сочетания FastAPI + Celery, но тут он вполне уместен. Отличная работа! Btw, не пробовали сочетание FastAPI + FastStream - интересны ваши мысли на этот счет
FastAPI + Redis + Celery: Создание системы временного хранения файлов с автоудалением и удобным веб-интерфейсом