Решение в лоб, простое и очевидное. Это плюс, если что. =)
Если работает, почему бы и нет.
Я бы сначала ткнулся сделать что-то типа ws['A1:J1'].value = heading, но если это не прокатит - то да, сделал бы по-твоему.
w0lkolak, нужно не путать терминологию.
Итерируемая коллекция (iterable) - объект, имеющий метод __iter__(). Метод возвращает итератор.
Итератор (iterator) - объект, имеющий метод __next__(). Он служит для перебора коллекции.
И да, неважно, к какому классу он принадлежит. Есть метод - можно работать.
pivodev, ну значит у них протокол общения разный, что не удивительно, игры-то на разных движках. Тогда твой код для CS2 не подойдёт. Я, увы, навскидку в гугле не нашёл описания протокола для CS2. Может, я плохо искал, конечно.
Rett-oo, вызывать (длительный) синхронный код из асинхронного и наоборот - муторно. Асинхронность - это не то, что можно "быстренько прикрутить сбоку". Ты или пишешь всю программу асинхронно, или не используешь асинхронность практически нигде. Промежуточные варианты возможны, но всегда доставляют непропорциональное количество хлопот.
Так что если нужны лимиты на RPS, т.е. троттлинг, то это легко реализуется асинхронно. У меня в ответах даже есть пример реализации. Лучше всё перетащить на асинхрон - или не перетаскивать ничего.
hardux2821, учи flask, читай примеры, думай головой. Суть проблемы я для тебя описал.
У тебя в шаблоне заявлена переменная encoded_image, а ты передаёшь при рендеринге переменную по имени photo_data. Также, судя по тому, что у тебя просто обращение к /photo работает - ты хранишь в БД файл как есть, в бинарном виде. Но при этом в шаблоне ты ожидаешь, что в переменной будет не бинарное представление, а строка, закодированная в base64.
Так что возьми содержимое photo_data, закодируй в base64, и результат передай вtemplate.render() под именем encoded_image. Как закодировать - гуглится.
Или, что я бы сделал, избавься от src="data:" в принципе. У тебя в приложении есть URL, который отдаёт картинку из базы? Ну вот на него и ссылайся в src.
DmitryNell, ну в случае обычного питона - это именно что подкаталог Scripts. Хотя, зависит от того, как ты его ставил, и как ставил библиотеку. Может лежать в папке профиля пользователя (AppData/Local вроде).
1. Для ответов на ответы есть механизм комментариев. Используй его.
2. А я говорю не про те переменные, которые были созданы раньше. Я говорю про совершенно посторонние. Если ты добавишь к именам префикс, это может помочь - но тебе придётся ОЧЕНЬ тщательно проверять, что никакая твоя переменная не начинается с этого префикса. Например, если у тебя все создаваемые переменные начинаются с "name_", но ты складываешь их имена в список name_list, то скорее всего в этом списке не будет лежать элемент "name_list" - а значит, пользователь сможет переопределить переменную name_list, и тем самым сломать твою логику проверки.
3. Сфига ли? Ничто не мешает класть в словарь объекты ткинтер.
Razraab, ну если очень на пальцах: асинхронная программа на питоне выполняется в одном потоке, от await'а до await'а. Когда попадает на await, текущая корутина приостанавливается, и программа выбирает другую - чей await выполнился, а значит, она готова продолжить выполнение. Вот так и скачет с одного места на другое. При этом обычно await связан с ожиданием операции ввода/вывода, явно или косвенно.
Прикол в том, что если у тебя длинная синхронная операция, то между двумя await'ами пройдёт много времени - и всё это время программа не сможет переключиться на другие корутины, пусть даже они уже готовы продолжаться. А значит, сетевая программа не сможет реагировать на поступающие данные, пока твоя синхронная операция не закончится.
Сколько времени будет "слишком много" - зависит от природы системы и нагрузки на неё. Но я бы сказал, что для фан проекта всё, что не очень часто выполняется и требует меньше секунды, можно игнорировать и выполнять синхронно. Вот, скажем, обращение к какому-нибудь сайту делать через синхронный requests не стоит, потому что это потенциально длительная операция. Лучше через асинхронный aiohttp.
С доступом к БД можно поспорить - многие говорят, что она тоже должна быть асинхронной, но для малонагруженного проекта сойдёт и синхронный доступ, как мне кажется.
А вот если надо сделать что-то длительное, но вычислительно нагруженное - вот тут и пригодится run_in_executor().
В твоём случае мне кажется, не будет вреда от синхронной генерации кода.
У тебя какая-то безумная логика тут, разобраться тяжело. И потом, а почему только Йошкар-Оле такая честь? А если на другую, букву, скажем, Я, все города исчерпаны, и кто-то назвал город, заканчивающийся на Я? Что тогда?
Может, стоит обобщить задачу?
