Он работает через mtproto, а не botapi, что может стать ограничением при масштабировании. Зато позволит использовать пару дополнительных методов и посылать файлы большего размера без поднятия доп сервера. А вот что там насчёт удобной работы с переходами и прочим - не знаю.
Телеграм не разрешает получать апдейты с нескольких "устройств". То есть вы не можете запустить несколько копий поллинга или настроить несколько хуков. В остальном, токен может юзать сколько угодно процессов, главное не выходить на лимиты запросов.
Чтобы не зависеть от внешних API надо их не использовать. Основная опасность тут: нарушение функциональности бота из-за влияния третей стороны. Это может быть недоступность по техническим причинам, смена формата API или юридические ограничения.
с недоступностью API из-за поломки его сервера вряд ли можно что-то сделать, только сотрудничать с провайдером API и договариваться о резервировании
смена формата API обычно не происходит внезапно, хорошие провайдеры стараются заранее предупреждать и обеспечивать совместимость хотя бы какое-то время
юридические ограничения (например санкции) я обсуждать скорее всего не смогу.
Если вы не хотите зависеть от API, вы должны либо полностью отказаться от его использования, либо иметь альтернативное решение, на которое можете переключиться прозрачно для пользователя.
Использование asyncio - не убирание зависимости, а лишь способ конкурентной обработки. Оно не решает никаких проблем вызванных наличием зависимости, только помогает работать в высококонкурентной среде. Вместо asyncio в каких-то случаях вполне подходит threading, а в каких-то - фоновая обработка с помощью очередей.
Указанный в пример "асинхронный код" на самом деле полностью синхронный, хоть и использует aiohttp - в нем все действия делаются строго по очереди. Чтобы что-то начало работать асинхронно надо как минимум запустить несколько задач по обработке, а ещё учесть как телеграм доставляет сообщения (например, число коннектов при вебхуках ограничено и он ждет успешного ответа на запрос).
Телеграм ругается только если у вас несколько копий делают polling. В случае вебхуков у вас идёт запрос на один урл, а дальше типичное масштабирование веб приложения
Ну тут вопрос для каких сценариев вы хотите это использовать. Очевидно, что если у вас группа на миллион участников и все могут нажать кнопку, то странно иметь сложное меню с состоянием и переходами - это будет затрагивать всех пользователей. Скорее всего тут будут более простые сценарии
Если же мы говорим о небольших группах или личной переписке - тут более вероятны сложные менюшки. Но тут и нет проблем с масштабированием - разные чаты мы можем обрабатывать параллельно без каких либо проблем.
И ещё подробностей, как в процессе исправления нашли критический баг приводящий к некорректной логике, а потом выяснилось, что на этот баг уже сделали костылей и его исправление ломает всё
lock в данном случае содержит результат блокировки, а сам лок
Если бы там был все таки Лок, мы бы получили двойную блокировку (одна из-за контекстного менеджера, вторая из-за aquire)
Если бы мы взяли RLock вместо Lock, это позволило бы внутри одного контекста повторно вызвать aquire, но код бы все равно не имел смысла, потому что Лок используется только в одном потоке
А почему? Если у вас сложные вычисления, то у вас скорее всего не будет переключения контекста, наоборот должно работать "быстрее". Другой вопрос, что никакой конкурентности при этом не будет
Интересная мысль с генерацией python-кода. Так же, мне нравится разделение кастомного кода бизнес логики и описание UI. Единственно, что пока не понятно как оно будет работать в больших ботах со сложной логикой. Сбор всех функций в один класс станет нецелесообразным - лучше разделить их по группам. Кроме того, в ботах есть часто повторяющиеся действия - чекбоксы, выбор из динамического списка вариантов, хранящихся в БД, что сразу просится для унификации. Было бы интересно посмотреть, что из этого выйдет.
У меня есть проект, тоже позволяющий описывать UI декларативно, но я не стал пока выносить это в YAML, а предлагаю описывать в виде python-кода (хотя ребята показывали как они генерируют мои объекты из yaml). И тут уже есть свобода создания кастомных компонентов, наследования для внедрения своей логики и т.п. Велкам на гитхаб: https://github.com/Tishka17/aiogram_dialog/. И вот поверх этого уже можно генерировать превью, диаграмму переходов (с определенными ограничениями). Простенькое демо нескольких фич доступно тут: https://t.me/aiogram_dialog_demo_bot (код демо).
Условно у меня это выглядит вот так:
Dialog(
Window(
Const("Greetings! Please, introduce yourself:"),
StaticMedia(
path=os.path.join(static_dir, "python_logo.png"),
type=ContentType.PHOTO,
),
MessageInput(name_handler, content_types=[ContentType.TEXT]),
MessageInput(other_type_handler),
state=DialogSG.greeting,
),
Window(
Format("{name}! How old are you?"), # dynamic text
Select( # dynamic buttons list
Format("{item}"),
items="ages", # retrieved from getter function
item_id_getter=lambda x: x.id,
id="w_age",
on_click=on_age_changed,
),
state=DialogSG.age,
getter=get_data,
),
)
"hello".captialize() и str.capitalize("hello") работает одинаково, используя один и тот же код.
Но второе может перестать работать, если вместо строки у вас что-то совместимое со строкой. Для строк может не так критично, а в других случаях - может выстрелить. В питоне все таки утиная типизация.
pathlib - это неплохой способ работы с путями, при условии что вам действительно нужна объектная модель. Во многих случаях его использование приводит к лишним конвертациям из строк в объекты и обратно. Я бы предложил в большинстве случае использовать os.path
В рамках данной статьи был константа с прямым слэшом /, это теоретически может привести к некорректному поведению, когда его будут комбинировать дальше с путями в ОС Windows, содержащими обратный слэш \
Не заметил чтобы эти затраты учитывались в расчете прибыльности в посте
Простите, а что за bot.send_messages? Не вижу в официальной документации телеграмма возможности отправлять сообщения пачками, только по одному.
Он работает через mtproto, а не botapi, что может стать ограничением при масштабировании. Зато позволит использовать пару дополнительных методов и посылать файлы большего размера без поднятия доп сервера. А вот что там насчёт удобной работы с переходами и прочим - не знаю.
Телеграм не разрешает получать апдейты с нескольких "устройств". То есть вы не можете запустить несколько копий поллинга или настроить несколько хуков. В остальном, токен может юзать сколько угодно процессов, главное не выходить на лимиты запросов.
Чтобы не зависеть от внешних API надо их не использовать. Основная опасность тут: нарушение функциональности бота из-за влияния третей стороны. Это может быть недоступность по техническим причинам, смена формата API или юридические ограничения.
с недоступностью API из-за поломки его сервера вряд ли можно что-то сделать, только сотрудничать с провайдером API и договариваться о резервировании
смена формата API обычно не происходит внезапно, хорошие провайдеры стараются заранее предупреждать и обеспечивать совместимость хотя бы какое-то время
юридические ограничения (например санкции) я обсуждать скорее всего не смогу.
Если вы не хотите зависеть от API, вы должны либо полностью отказаться от его использования, либо иметь альтернативное решение, на которое можете переключиться прозрачно для пользователя.
Использование
asyncio- не убирание зависимости, а лишь способ конкурентной обработки. Оно не решает никаких проблем вызванных наличием зависимости, только помогает работать в высококонкурентной среде. Вместо asyncio в каких-то случаях вполне подходитthreading, а в каких-то - фоновая обработка с помощью очередей.Указанный в пример "асинхронный код" на самом деле полностью синхронный, хоть и использует
aiohttp- в нем все действия делаются строго по очереди. Чтобы что-то начало работать асинхронно надо как минимум запустить несколько задач по обработке, а ещё учесть как телеграм доставляет сообщения (например, число коннектов при вебхуках ограничено и он ждет успешного ответа на запрос).Телеграм ругается только если у вас несколько копий делают polling. В случае вебхуков у вас идёт запрос на один урл, а дальше типичное масштабирование веб приложения
У вас решение за квадрат (из-за срезов)
Ну тут вопрос для каких сценариев вы хотите это использовать. Очевидно, что если у вас группа на миллион участников и все могут нажать кнопку, то странно иметь сложное меню с состоянием и переходами - это будет затрагивать всех пользователей. Скорее всего тут будут более простые сценарии
Если же мы говорим о небольших группах или личной переписке - тут более вероятны сложные менюшки. Но тут и нет проблем с масштабированием - разные чаты мы можем обрабатывать параллельно без каких либо проблем.
Как будто windows 7 и windows XP поддерживаются сами по себе
И ещё подробностей, как в процессе исправления нашли критический баг приводящий к некорректной логике, а потом выяснилось, что на этот баг уже сделали костылей и его исправление ломает всё
Он не работает.
lock в данном случае содержит результат блокировки, а сам лок
Если бы там был все таки Лок, мы бы получили двойную блокировку (одна из-за контекстного менеджера, вторая из-за aquire)
Если бы мы взяли RLock вместо Lock, это позволило бы внутри одного контекста повторно вызвать aquire, но код бы все равно не имел смысла, потому что Лок используется только в одном потоке
А лучше вообще отказаться от синглтона, а просто создать один экземпляр и инжектировать в адаптер, который его использует.
А почему? Если у вас сложные вычисления, то у вас скорее всего не будет переключения контекста, наоборот должно работать "быстрее". Другой вопрос, что никакой конкурентности при этом не будет
Интересная мысль с генерацией python-кода. Так же, мне нравится разделение кастомного кода бизнес логики и описание UI. Единственно, что пока не понятно как оно будет работать в больших ботах со сложной логикой. Сбор всех функций в один класс станет нецелесообразным - лучше разделить их по группам. Кроме того, в ботах есть часто повторяющиеся действия - чекбоксы, выбор из динамического списка вариантов, хранящихся в БД, что сразу просится для унификации. Было бы интересно посмотреть, что из этого выйдет.
У меня есть проект, тоже позволяющий описывать UI декларативно, но я не стал пока выносить это в YAML, а предлагаю описывать в виде python-кода (хотя ребята показывали как они генерируют мои объекты из yaml). И тут уже есть свобода создания кастомных компонентов, наследования для внедрения своей логики и т.п. Велкам на гитхаб: https://github.com/Tishka17/aiogram_dialog/. И вот поверх этого уже можно генерировать превью, диаграмму переходов (с определенными ограничениями). Простенькое демо нескольких фич доступно тут: https://t.me/aiogram_dialog_demo_bot (код демо).
Условно у меня это выглядит вот так:
Питон НЕ проверяет тайпхинты в процессе выполнения. Надо использовать ДО запуска отдельные инструменты типа mypy/pyright.
Но второе может перестать работать, если вместо строки у вас что-то совместимое со строкой. Для строк может не так критично, а в других случаях - может выстрелить. В питоне все таки утиная типизация.
Даже лучше соответствует определению интерфейса, так как не заставляет указывать что вы его реализуете (в отличие от джавы)
Если вы не используете пути как объекты, а везде вам нужны строки, то все возжности покрываются
os.path.pathlib- это неплохой способ работы с путями, при условии что вам действительно нужна объектная модель. Во многих случаях его использование приводит к лишним конвертациям из строк в объекты и обратно. Я бы предложил в большинстве случае использоватьos.pathВ рамках данной статьи был константа с прямым слэшом
/, это теоретически может привести к некорректному поведению, когда его будут комбинировать дальше с путями в ОС Windows, содержащими обратный слэш\Всё ещё не понимаю, почему её форсят некоторые люди:
у нее достаточно сложная минимальная настройка из-за необходимости интеграции с logging
у нее не очень высокая гибкость (коллеги жаловались на сложности кастомизации хэндлеров)
у нее ужасно многословные трейсы по дефолту