Есть асинхронный модуль для отправки писем на email?

Question

[Dream]

Есть ли асинхронная библиотека для отправки писем на любой email? (mail, gmail, yandex и т.д.). Пользовался библиотекой от python, но она синхронная и я заметил, что письма отправляются только на gmail.

ЯП - Python

Answer 1

[antares4045]

Вообще то стандартная питоновская либа просто реализует протокол подключения к POP серверу, так что она способна работать с любой почтой.

Скорее всего вы просто отправляли письма с неблагонодёжного сервера (или аккаунта).

по поводу синхронности: существует модуль threading (ну или asyncio (который, не смотря на свою хайповость, ̶р̶а̶б̶о̶т̶а̶е̶т̶ ̶т̶а̶к̶ ̶с̶е̶б̶е̶ мне не нравится))

настоятельно рекомендую изучить примеры использования threading.Thread для решения вашей проблемы

Comments

[Dream]

Насчет отправки письма: использовал gmail

[antares4045]

Dream, А. ну всё логично.

используйте просто email

https://docs.python.org/3/library/email.examples.html
https://python-scripts.com/send-email-smtp-python

[shurshur]

antares4045

ну или asyncio (который, не смотря на свою хайповость, работает так себе)

Работает он нормально, просто им надо уметь пользоваться. Разумеется, при неправильном использовании он будет работать "так себе", но это уже проблема кривых рук использующего.

[antares4045]

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

async def a():
  def b():
    await c()
  b()

причём из-за непреодолимых обстоятельств, вложеную функцию никак нельзя было превращать в корутину.
я потратил часов 8 на гугление и пришёл к выводу, что текущая реализация asyncio настолько "нормальна", что мне пришлось городить костыль, ломающий психику любому, его прочитавшему (если интересно, могу скинуть)

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

[Roman K]

antares4045, так это твоя проблема. На первых строчках (до 3.9 было про run_in_executor, который актуален для CPU-bound и сейчас) документации по асинку говорится, как синхронную функцию запускать в асинхронной, чтобы ее не блокировать.

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

[antares4045]

Roman Kitaev, был почти уверен, что мне начнут объяснять, что я решаю не ту задачу, но в этом то и кроется проблема:
надо было собрать композицию из функций из трёх библиотек, две из которых были асинхронными. у меня нигде не было доступа, к месту, в которых функции по факту вызывались: я просто отдавал их калбеками. запуск синхронной функции.
Тем не менее отмечу, что я действительно не дочитал до конца официальные доки в тот раз. Моя проблема разрешима в рамках одного лишь asyncio при помощи конструкции:

async def a():
    def b():
        asyncio.run(c())
    await asyncio.get_running_loop().run_in_executor( None, b)

С с эстетической точки зрения она меня всё ещё коробит, но меньше моего предыдущего решения: это уже похоже на тот путь, которым могли авторы библиотеки разрешать проблему косвенной рекурсии. но не говорите мне, что это не костыль, вставленный в истеричной попытке подружить libuv с GIL.

[Roman K]

antares4045, libuv давно подружили. Называется uvloop. Как и зачем её дружить c GIL — непонятно. Это вещи из разных миров.

[shurshur]

antares4045, это проблема не асинхронного подхода, а именно непонимания того, как оно работает. Нужно просто понимать, что asyncio - это "что-то типа тредов, но без тредов", и из этого вытекают достоинства и недостатки.