Здесь есть гуру чистого кода? Как можно оэтовот улучшить? Суть

такова: есть бот, в котором есть команда /leaderboard. Она должна выводить по 10 участников на страницу, а всего их - 100 (участников). Само по себе оно, как бы, работает, но сам код меня не очень удовлетворяет, а что конкретно, понять не могу 😅

Ух.. 1. у тебя весь код свален в кучу и делает все сразу. - выборка данных - представление данных - отправка данных 2. list comprehension с простыней запроса внутри выглядит странно. 3. перебирать список и пропускать 9 подряд итераций чтобы получить 10ю выглядит тоже странно. что мешало взять range ?

1. Получается, стоит разбить по отдельным функциям? 2. Убрать list comprehensions и добавить его сразу туда, куда надо? (ну или вынести в отдельную переменную?) 3. ааа.. ээ.. ну попробую что-то с range, лан 4. а да?

1. Для начала, да 2. Если у тебя в компрехеншене более 2-3 вызовов, то это мгновенно говно. Используй обычные циклы 3. Зачем тебе вообще тут цикл с перебором элементов в level_data? Просто возьми len, подели нацело на десять и сформируй соответствующее количество выдачи 4. Да

Бтв к вопросу про то, зачем нужны все эти задачи на нахождение простых чисел, выведение остатков и прочее

Пока как надо изменяю или ошибку на ошибку исправил?

Убери компрехеншены. Вот просто не используй их, если у тебя пока "вкус" не сформирован когда это стоит использовать, а когда нет

Вкус...

А с компрехеншеном-то тут что? Вот то что контекст для форматирования строки собирается прямо по месту — портит читаемость, а в остальном не вижу катастрофы.

Замена компрехеншена циклом изменит что? Правильно, ничего.

Ну ты строку внутри компрехеншена не сформируешь нормально, давай начнем с этого. Отказ от компрехеншена это необходимое условие

И да, что мешает тут дебажить?

Why?

Предположим избавился я от компрехенша и сделал такое: iterable_data = [i async for i in self.get_leaderboard_data(guild_id=inter.guild_id, limit=100)] level_data = self.generate_leaderboard_data(interaction=inter, data=iterable_data) Насовсем не хочу избавляться, иначе iterable_data будет таким iterable_data = [] async for i in self.get_leaderboard_data(guild_id=inter.guild_id, limit=100): iterable_data.append(i) Тут уж лучше с ним, как по мне

Вот лучше тут f-строку используй, у тебя уже сформированы параметры, подставлять их нормально через f-строки. Не надо в f-строках вызовы делать какие-то

Куча вызовов внутри строки, дебаггер ее за 1 инструкцию считает и между вызовами не понять что происходит нормально

Покажи как сформировать и разложить по переменным

1. Внутри строки или внутри компрехеншена? Ты уж определись, к чему придираешься? 2. С чего ты решил, что дебагер будет считать это одной инструкцией? Точки останова и хождение по шагам прекрасно работают и внутри комрпхеншена и внутри форматной строки, если они разнесены на несколько строк.

Ты знаешь чем необходимо условие и достаточное различаются?

Ну объясняй. Пока я вижу ложное утверждение о том, что "дебаггер ее за 1 инструкцию считает и между вызовами не понять что происходит нормально".

С дебаггером вышел обсер, да. Тем не менее, это не является предметом основного обсуждения. Еще раз -- для нормального составления строки нужно вынести получение значений в отдельные переменные И этот вынос в компрехеншене нормально сделать нельзя => от компрехеншена нужно отказаться. Отсюда следует, что для нормального составления строки нужно отказаться от компрехеншена. Я максимально подробно расписал насколько смог

Что значит "нельзя"? [ f"{value.param1} - {value.param2} - {value.param3}" for value in some_iter ] Так тебя тоже пугает? Весь вопрос к предложенному коду тут в том, что он пытается делать несколько вещей одновременно. Вынести эту генерацию в отдельную функцию, возвращающую итератор из датаклассов, словариков, namedtuple или чего-то такого — и всё прекрасно кладётся в компрехеншен. А со сложной логикой — что там, что там проблема.