Ну да, фреймворки не нужны Да и языки программирования не нужны, они ведь все равно все одинаково транслируются в машинный код

Так зачем нужен фреймворк для Bot API если всё укладывается в одну функцию?

Так зачем нужен фреймворк для Bot API если всё укладывается в одну функцию?

Зачем вообще нужны фреймворки?

Для удобства

Зачем вообще нужны фреймворки?

Чтобы упрощать разработку.

Для удобства

Для этого тоже.

Так зачем нужен фреймворк для Bot API если всё укладывается в одну функцию?

Ооо даааа, а потом у тебя if-else на дохулиард условий, когда начинаешь парсить сообщения

Ооо даааа, а потом у тебя if-else на дохулиард условий, когда начинаешь парсить сообщения

Например? Поясни.

У меня просто все боты без фреймворков, я вот лох по местным меркам.

Хочу понять кейс.

Например? Поясни.

Я с телефона, погоди немного

Зачем X будет ставить фреймворк для Bot API.

Чтобы упрощать разработку.

Воооот Поэтому проще сделать composer require botman и написать пару строк фасадов Чем городить немасштабируемый огород из функций

Воооот Поэтому проще сделать composer require botman и написать пару строк фасадов Чем городить немасштабируемый огород из функций

Позвольте! Ну почему огород и почему немасштабируемый? Нужно выставить вебхук и отправить sendMessage.

Если очень базово.

А если очень-очень базово. file_get_contents(...);

А если очень-очень базово. file_get_contents(...);

Это, конечно, плохая идея, это просто пример.

Чтобы отправить одно сообщение - мне нужно две строчки, http_build_query и file_get_contents.

Позвольте! Ну почему огород и почему немасштабируемый? Нужно выставить вебхук и отправить sendMessage.

Потому что если нужно отправить дополнительно клавиатуру, что тогда? Если нужно выключить превью ссылок? А если через год в тг поменяется название параметра, кто будет вспоминать где он в коде засунут?

Потому что если нужно отправить дополнительно клавиатуру, что тогда? Если нужно выключить превью ссылок? А если через год в тг поменяется название параметра, кто будет вспоминать где он в коде засунут?

Если нужно выключить preview, то отправляется параметр с false в строке с http_build_query.

С клавиатурами всё геморройно, есть такое ?

Хочу понять кейс.

У тебя есть бот, который ловит 3 команды и ещё одно действие, если написал админ. Без фреймворка: 1) делаешь метод, который делает запросы в телегу 2) пишешь метод для получения апдейтов, парсишь json 3) херачишь длинный if-else по одному на каждую команду + один для определённого ID.

Но всё-таки в основном фреймворки для Bot API как раз усложняют разработку в итоге.

С фреймвором (питон) 4 аккуратных хэндлера, код простой и читабельный

Типа on('message', ... ?

У тебя есть бот, который ловит 3 команды и ещё одно действие, если написал админ. Без фреймворка: 1) делаешь метод, который делает запросы в телегу 2) пишешь метод для получения апдейтов, парсишь json 3) херачишь длинный if-else по одному на каждую команду + один для определённого ID.

Да, всё так (разве что длинный if-else совершенно не обязательно делать), но я всё равно не понимаю, как тут поможет фреймворк, если там происходит то же самое.

Только скрыто от тебя в либе.

Я могу свои функции тоже в либу захуярить.

эм

так захуярь

в этом и смысл, в общем-то

Но всё-таки в основном фреймворки для Bot API как раз усложняют разработку в итоге.

Ну раз так, бот апи так то вообще не нужен Взаимодействие с ботами - это ещё один слой апи, так что рекомендую написать нативный клиент, который через ихний бинарный протокол будет напрямую работать с ботами

ты же сам сообщений 20 назад ответил на свой вопрос)

Ну смотри. https://github.com/MasterGroosha/telegram-tutorial/blob/master/lesson_08/bot.py 3 аккуратных метода: для сообщений, для колбэков, для инлайна. Хочешь сказать, что БЕЗ фреймворка код получится проще, меньше и читабельнее?

Ну раз так, бот апи так то вообще не нужен Взаимодействие с ботами - это ещё один слой апи, так что рекомендую написать нативный клиент, который через ихний бинарный протокол будет напрямую работать с ботами

Тогда даже http_build_query не понадобится

Ну смотри. https://github.com/MasterGroosha/telegram-tutorial/blob/master/lesson_08/bot.py 3 аккуратных метода: для сообщений, для колбэков, для инлайна. Хочешь сказать, что БЕЗ фреймворка код получится проще, меньше и читабельнее?

Ну будет три условяи.

Экономим процессорные циклы, нагнетаем простоту в коде

Ну смотри. https://github.com/MasterGroosha/telegram-tutorial/blob/master/lesson_08/bot.py 3 аккуратных метода: для сообщений, для колбэков, для инлайна. Хочешь сказать, что БЕЗ фреймворка код получится проще, меньше и читабельнее?

ну так там же внутри либы тот же самый код!11

А тут 3 def'a.

Велика беда.

Хорошо, секунду

Не кормите тролля

Не кормите тролля

Ну почему сразу тролля?

мне что-то не нравится @ мам, меня троллят

Ну почему сразу тролля?

Потому что жырно слишком

Что жирного?

https://github.com/MasterGroosha/telegram-xkcd-password-generator/blob/master/xkcd_passwords_bot.py Вот побольше условий. Посчитай уровень вложенности для твоего случая + клавы + их редактирование + работа с БД

То, что я не использую фреймворки для ботов?

Фреймворки нужны чтобы упрощать разработку @ Фреймворки для бот апи все усложняют

Я вот пришёл сюда и задал профильный вопрос.

Фреймворки нужны чтобы упрощать разработку @ Фреймворки для бот апи все усложняют

Да, поэтому они не нужны.

https://github.com/MasterGroosha/telegram-xkcd-password-generator/blob/master/xkcd_passwords_bot.py Вот побольше условий. Посчитай уровень вложенности для твоего случая + клавы + их редактирование + работа с БД

Сейчас гляну.

Это telebot?

Да, поэтому они не нужны.

Использование фреймворков позволяет тратить меньше времени на подготовку к реализации логики и больше на саму логику. То, что нужно.

С клавиатурами всё геморройно, есть такое ?

Это telebot?

pyTelegramBotAPI

Пина нет, но можно ботом запостить сообщение, запинить его и редачить потом сколько влезет.

Не. Цель в том, чтобы бот алярмил участников чата по ключевым словаи

М

Всем привет, не особо тематический вопрос: а где можно о своём боте рассказать?

Использование фреймворков позволяет тратить меньше времени на подготовку к реализации логики и больше на саму логику. То, что нужно.

@bot.message_handler(commands=["start"]) bot.send_message(message.chat.id, texts.text_start, parse_mode="HTML") ... @bot.message_handler(commands=["help"]) bot.send_message(message.chat.id, texts.text_help, parse_mode="HTML") Почему это хуже: j = json.loads(req) if j['message']['text'] == '/start': params = {"foo": "bar"} yourReqFunc(j['message']['chat]['id'], params) if j['message']['text'] == '/help': params = {"foo": "bar"} yourReqFunc(j['message']['chat]['id'], params)

Хахахах

Потому что это не читается?

@bot.message_handler(commands=["start"]) bot.send_message(message.chat.id, texts.text_start, parse_mode="HTML") ... @bot.message_handler(commands=["help"]) bot.send_message(message.chat.id, texts.text_help, parse_mode="HTML") Почему это хуже: j = json.loads(req) if j['message']['text'] == '/start': params = {"foo": "bar"} yourReqFunc(j['message']['chat]['id'], params) if j['message']['text'] == '/help': params = {"foo": "bar"} yourReqFunc(j['message']['chat]['id'], params)

Как минимум, потому что у тебя может отсутствовать text :) Вылетит исключение

Как минимум, потому что у тебя может отсутствовать text :) Вылетит исключение

if not 'message' in j:

Но я твой поинт понял.

Ты делаешь дополнительный if, там вылетает ещё исключение, и так далее

Фреймворк имеет все эти дополнительные штуки, но мне кажется, что их так мало, что нет смысла ради этого что-то ставить.

А вам кажется, что их достаточно много.

В итоге у тебя 100500 if-else, тебе надо контролировать, куда вставлять новый и так далее

Фреймворк имеет все эти дополнительные штуки, но мне кажется, что их так мало, что нет смысла ради этого что-то ставить.

Угу, а то мало ли, ещё и место на диске кончится

Угу, а то мало ли, ещё и место на диске кончится

Не понял шутки.

Дело не в месте на диске, а в понятной структуре проекта + его нагрузке.

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

Дело не в месте на диске, а в понятной структуре проекта + его нагрузке.

Ага, то есть спагетти код, который непонятно что делает, это понятная структура?

Но я твой поинт понял.

Считаем if: 1) какого типа апдейт 2) какого типа сообщение или какого типа инлайн/колбэк (это уже строчек 50 одних лишь if-else) 3) потом if по командам/id и т.д. А теперь – фаталити! Реализуй без фреймворков пошаговые действия (конечный автомат состояний) Уверен, в лучших BDSM-клубах мира тебе не доставят такую боль, которую ты испытаешь, решая эту задачу без фреймворков

Ага, то есть спагетти код, который непонятно что делает, это понятная структура?

То есть без фреймворка нельзя написать читаемый код?

И почему сразу спагетти?

Я тоже использую функции.

То есть без фреймворка нельзя написать читаемый код?

Можно, но зачем, если все давно написано и выложено в пакете?

Считаем if: 1) какого типа апдейт 2) какого типа сообщение или какого типа инлайн/колбэк (это уже строчек 50 одних лишь if-else) 3) потом if по командам/id и т.д. А теперь – фаталити! Реализуй без фреймворков пошаговые действия (конечный автомат состояний) Уверен, в лучших BDSM-клубах мира тебе не доставят такую боль, которую ты испытаешь, решая эту задачу без фреймворков

Я понял твой поинт, да. Но я всё-таки не соглашусь, у меня есть один бот с инлайном и коллбеками, всё определяется первым ключиком в сообщении. Пишется case и всё понятно (никакой лапши).

Господа, а давайте проведём эксперимент!

Почему сразу ассоциация с говнокодом - не понимаю.

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

Я не понимаю, почему это плохо и нечитаемо. Мне кажется, всё предельно понятно.

Денаим сообщение при определённых условиях.

ТЗ: 1) на входящую картинку отвечать file_id 2) на команду /start спрашивать число, если введено число, спрашивать букву. 3) когда по очереди переданы число и буква, вернуть их вместе 4) на любой инлайн предлагать текст "Telegram" Товарищ с иероглифами пишет без фреймворка, кто-то другой пишет на том же ЯП с использованием фреймворка. Потом сравниваем

Я не понимаю, почему это плохо и нечитаемо. Мне кажется, всё предельно понятно.

Это уже логика бота, к фреймворкам мало имеет отношения

Так зачем нужен фреймворк для Bot API если всё укладывается в одну функцию?

исключения, тесты и т.д

ТЗ: 1) на входящую картинку отвечать file_id 2) на команду /start спрашивать число, если введено число, спрашивать букву. 3) когда по очереди переданы число и буква, вернуть их вместе 4) на любой инлайн предлагать текст "Telegram" Товарищ с иероглифами пишет без фреймворка, кто-то другой пишет на том же ЯП с использованием фреймворка. Потом сравниваем

Это подразумевает же использование сессий каких-то, т.е. нужно запоминать state человека, который пишет боту.

Что он отправил X сообщений назад.

Это подразумевает же использование сессий каких-то, т.е. нужно запоминать state человека, который пишет боту.

Конечно, конечный автомат.

Обычная ситуация для бота

А кто как кстати это реализует? Я обычно Redis подключаю или Memcached.

Лол, enum+shelve/vedis

Но не суть. Ты готов?

Да, хотя я не уверен, что закончу сейчас же.

А никто не торопит. Выбирай ЯП

а можно я в жюри буду ?

Не будет жюри. Просто участники выложат код, а остальные выскажутся