Как ни банально это звучит, но можно сказать и так, что мир просто сошёл с ума :) Сейчас стало не интресно писать быстрые, эффективные и экономичные приложения. Памяти у всех должно быть много, и сожрать гигабайт-другой от неё для никчёмной функциональности очередной модной приложухи никого в наше время не смущает.
Я бы ещё мог понять, если бы это было для приложений, которые бы использовались для основной работы на текущем компьютере. В конце концов, можно смириться с тем, что фронтальное приложение потребляет значительную часть ресурсов. Беда в том, что все (реально, 100%) электронных приложений, с которыми мне доводилось иметь дело, были различными мессенджерами. То есть приложение, основная функция которого состоит в банальном обмене небольшими текстовыми сообщениями в параллельно запущенном с основной работой процессе, обязательно требует свой "законный" гигабайт оперативной памяти, по любому чиху глючит и по желанию левой пятки вытекает (в том числе даже и в своп). И всё это по причине острого нежелания писать нативный кроссплатформенный код. Типа пусть кроссплатформенным будет тяжёлый браузер с неповоротливым js-интерпретатором, юзер не развалится запускать эти браузеры пачками.
Великое счастье, что пока ещё не нужно подобные поделия ставить десятками, потому что подобных приложений пока ещё не так много. Но с учётом огромного количества недорогих js-разработчиков на рынке мы можем скоро придти и к этому. Мне слабо верится, что всякие WebAssembly как-то принципиально улучшат ситуацию. Скорее даже нет, просто все ломанутся ещё больше криво говнокодить приложухи и ещё больше съедать ресурс оперативной памяти пользователей.
zerx1, с syn flood лучше бороться с помощью более правильных инструментов, например, iptables. Такой скрипт на Python интересен разве что в образовательных целях.
aab137, как любили говорить в 90-х, "а кому сейчас легко?"
Конечно, надо изучать, как там всё устроено. Какие браузер делает запросы, какие у них параметры, откуда берутся... Если повезёт и устроено не очень сложно, то можно будет повторить, не изучая js-код, а лишь осознав логику используемого API. Но я бы не стал на это особенно сильно рассчитывать.
Ошибка вполне понятна - в функцию передано значение неверного типа, но толку от неё в такой формулировке нет. Ошибка нужна в контексте - в какой строке она происходит?
1. Автор хочет получить список участников чужого сервера, на котором его бота владелец не добавил и не добавит. Без добавления бота на этот сервер ничего не получится, вообще никак.
Vindicar, по умолчанию и так системная локаль используется, поэтому у автора она явно не та, что нужно. Либо, как вариант, при его способе запуска приложения (systemd?) локаль оказывается не определена или определена не в то значение.
ruslanbm29, как тупое решение: по сути в этом шаблоне слева направо идут ветвления текста, можно просто нумеровать перебираемые варианты, тогда каждый будет кодироваться ключом id_шаблона+список_вариантов_выбора. Но шаблоны менять будет нельзя, только добавлять новые, иначе все ключи поедут.
Morrowind, ну очевидно же что ошибка случается в недрах psycopg2.connect, из-за чего случается exception до присваивания connection. Простейшее решение: перед try: вставляем connection = None. Тогда при любом исключении connection будет определён хоть каким-то значением.
Morrowind, интерпретатор не может быть "уверен" или "не уверен", у него в строке 203 файла /server/DataFormatCorrection/UpdateData.py не определена переменная connection, и если на другой системе подобного поведения не было, значит, там переменная была определена. Эти ситуации не могут быть аналогичными. Ссылки на "раньше работало" тут бессмыслены. Нужно исправлять проблему, а не искать в ней скрытый смысл.
Я бы ещё мог понять, если бы это было для приложений, которые бы использовались для основной работы на текущем компьютере. В конце концов, можно смириться с тем, что фронтальное приложение потребляет значительную часть ресурсов. Беда в том, что все (реально, 100%) электронных приложений, с которыми мне доводилось иметь дело, были различными мессенджерами. То есть приложение, основная функция которого состоит в банальном обмене небольшими текстовыми сообщениями в параллельно запущенном с основной работой процессе, обязательно требует свой "законный" гигабайт оперативной памяти, по любому чиху глючит и по желанию левой пятки вытекает (в том числе даже и в своп). И всё это по причине острого нежелания писать нативный кроссплатформенный код. Типа пусть кроссплатформенным будет тяжёлый браузер с неповоротливым js-интерпретатором, юзер не развалится запускать эти браузеры пачками.
Великое счастье, что пока ещё не нужно подобные поделия ставить десятками, потому что подобных приложений пока ещё не так много. Но с учётом огромного количества недорогих js-разработчиков на рынке мы можем скоро придти и к этому. Мне слабо верится, что всякие WebAssembly как-то принципиально улучшат ситуацию. Скорее даже нет, просто все ломанутся ещё больше криво говнокодить приложухи и ещё больше съедать ресурс оперативной памяти пользователей.