valexeich, ну так не долби так часто. Лимиты стима придётся определять опытным путём, там может быть число попыток в час, в день и так далее. Допустим, один и тот же IP можно использовать не чаще, чем раз в час - тогда тебе для круглосуточной работы понадобится 360 различных рабочих прокси. И это еще очень щедрая оценка лимитов!
менять ip для каждого запроса с помощью tor, но не помогло
Tor вообще-то не для этого. Выходных узлов мало, они известны, и ряд сайтов их блочит превентивно.
Нужно либо играть по правилам стима, либо иметь 100500 рабочих прокси.
Ну и да, долбить стим маркет раз в 10 секунд... что за игры в высокочастотный трейдинг? Нафига?
MaxBat, ну тогда только этот вызов и запихивай в run_in_executor(). А вообще это стоило пометить в комментах к коду.
А что это за синхронный код, кстати? Потому что если это какой-нибудь скрапинг сайта с requests, то есть либы вроде aiohttp.
Максим Припадчев, я бы предположил что метакласс или что-то подобное. При создании класса-потомка StateMachine ищет в его __dict__ все имена, которым присвоен объект State(), на их основании строит список состояний, а дальше ищет имена методов, базируясь на именах состояний.
Rouzi, в видео этот момент пошагово описывается.
Сопоставляешь каждой вершине информацию - как быстро её можно достичь (назовём это вес), и из какой вершины (шаг пути).
Поначалу для всех вершин вес будет +бесконечность, а шаг пути будет отсутствовать. Для стартовой будет вес 0.
Потом перебираешь все вершины, у которых вес не +бесконечность. Назовём их "известными".
Для каждой такой вершины перебираешь соседние вершины, т.е. те, которые с ней связаны напрямую ребром графа. Как их определить - зависит от того, как ты хранишь граф. Так что дальше вложенный цикл.
Для каждой соседней вершины проверяешь условие: вес текущей известной вершины + вес ребра от текущей известной к текущей соседней должны быть меньше, чем вес соседней вершины. Если условие выполняется, то для текущей соседней вершины запоминаешь её новый вес (сумма весов из условия) и её шаг пути (текущую известную вершину). Также взводишь логический флаг - было изменение веса.
Эти два вложенных цикла повторяешь до тех пор, пока логический флаг взведён, т.е. пока в рамках цикла ты обновил хоть одну вершину. Когда обновлений не произошло - ты просчитал весь граф, можно строить путь.
После этого путь строить просто. Начинаешь из вершины-пункта назначения, и смотришь, какая вершина сохранена для неё как "шаг пути". Идёшь туда, смотришь для той вершины шаг пути. И так пока не придёшь в точку отправления.
MegaEdwards, очень просто. У тебя же где-то хранится список открытых тикетов? В БД, или еще в каком хранилище. Если нет, то стоит сделать, иначе при перезапуске бота открытые тикеты потеряются.
Ну так просто для каждого тикета храни ID ассоциированного с ним сообщения. Тогда, получив on_raw_reaction_add, ищешь тикет с таким ID сообщения в хранилище. Если нашёлся - обслуживаем этот тикет согласно его состоянию и поставленной реакции. Если нет - молча игнорируем, или ещё что делаем.
s4q, ну так я на то и намекаю. Пока ты не сформулируешь критерий оптимальности маршрута, ничего не попишешь.
Самый короткий маршрут всегда будет прямой A -> B.
Если брать самый "жадный" маршрут (т.е. ехать всегда в ближайшее к текущему отделение), то можно, как это ни смешно, начать выписывать вензеля по карте.
Минимальный вариант я привёл выше - если ты сможешь для каждой точки определить те, с которыми она может быть связана, то у тебя получится взвешенный граф, в котором можно искать кратчайший путь алгоритмом Дейкстры. Простейший способ это сделать - наложить ограничение на длину одного переезда.
А если у тебя задача практическая, то тут вообще убиться можно, потому что ещё есть такие вещи как пропускная способность дорог, вместимость и пропускная способность отделений, и так далее, и так далее. Т.е. если многие оптимальные маршруты ведут через одно и то же отделение, это может замедлить дело, так как отделение будет перегружено.
s4q, этих сведений мало. Почему в твоём примере нельзя сразу сделать прыжок A -> B? Какие точки считаются "соседними"? А вообще есть классический алгоритм дейкстры.
MIHUTKA, так. А оригинальный запрос тоже post? Или всё же GET?
Ну а так, отвечает тебе даже не сам сайт, а его CDN, и скорее всего ему не нравится твой бот. Маскируйся лучше, заголовки запроса там, куки...
Какие сообщения об ошибке?
Как запускаешь питоновский файл?