Максим Припадчев

Например, вот так:

def GenerateAll(source, rep):
  for comb in itertools.combinations(range(len(source)), len(source)-len(rep)):
    s = list()
    prev = 0
    for (i, j) in enumerate(comb):
      s.append(source[j]);
    yield "".join(s)

Обратите внимание, перебираем не сочетания из удаляемых позиций, а из 22 оставляемых (кстати, у вас числа не бьются, 48+22 = 60 != 64). Тут порядок в ответе будет обратный (первая строка будет "xxxxxx...xxxx12..." а не "12..xxx..xx". Если нужен тот же порядок, то будет чуть сложнее:

def GenerateAll(source, rep):
  for comb in itertools.combinations(range(len(source)), len(rep)):
    s = list()
    prev = 0
    last = 0
    for (i, j) in enumerate(comb):
      while (last < j):
          s.append(source[last]);
          last += 1
      last += 1
    while (last < len(source)):
          s.append(source[last]);
          last += 1
    yield "".join(s)

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

Никак. Выбор инструмента - это задача тимлида и/или техлида. Т.е. ведущего/главного разработчика, отвечающего за принятие ключевых технических решений. Ваша задача, как заказчика, четко оформить требования, ограничения и сформировать начальное ТЗ и описание, что вам требуется от проекта, прототипы интерфейса, например. Без вникания в технические детали. Т.е., "хочу чтобы были фичи такие-то и работил они так-то, ограничения такие-то, требования такие-то". Далее уже задача найти разработчика/команду с большим или достаточным для данного проекта опытом. Далее из начального ТЗ формируется полноценное техническое задание: описывается весь требуемый функционал, рисуется дизайн, прописываются требования, ограничения и прочие хотелки. И на основе ТЗ, тим/тех лид уже подбирает/подбирают наиболее оптимальные и конкретные инструменты и решения, основываясь на собственном опыте и знаниях для конкретно этой задачи. Например, если человек хорошо знает несколько разных инструментов и есть достаточный опыт их использования - он может реализовать проект используя любой из них как одинаково хорошо, так и одинаково плохо. У разных ЯП и фреймворков свои плюсы и минусы. Далее из ТЗ формируется более детальное ЧТЗ и происходит разработка проекта.

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

А так - уже правильно посоветовали сразу брать дот-нет, т.к. у вас требование к использованию конкретной библиотеки для дот-нета.

Поясню ответ Алан Гибизов: Обратный слэш (\) в строковых литералах Питона (как и во многих языках) имеет специальное значение, зависящее от следующего символа. Например, \n означает символ перевода строки, \t - символ табуляции, и т.д. Последовательность \u позволяет задать символ юникода по его коду, например, символ \u00A7 это значок параграфа (§). Но это также разделитель каталогов в пути на платформе Windows. А у тебя в пути есть последовательность "C:\Users\777\Desktop\Новая папка\67.png".
Избежать этого конфликта можно одним из трёх способов:
* использовать последовательность \\ - она означает просто символ \ без специального поведения.
* использовать "сырой" строковой литерал - my_path = r'C:\Users\'. В таких литералах символ \ не имеет специального поведения, это просто символ.
* Записать путь, используя прямой слэш /. Винда это позволяет.

Попробуйте варианты:
Поставить r перед строкой пути
my_path = r'C:\Users\'
Задвоить все слеши
my_path = 'C:\\Users\\'
Заменить все слеши на обратные
my_path = 'C:/Users/'

Сам словарь полученный от телеграмм мне нужно его в нужном моменте сохранять в бд, а позже вытаскивать обратно превращая назад в dict, но все идет по наклонной

Ну т.е. как и предсказывали, проблема в более раннем коде.
Когда сохраняешь в БД, делай не str(mydict), а json.dumps(mydict). Тогда можно будет делать json.loads() при загрузке.

Только словарь надо будет почистить от постороннего, а ещё лучше - сначала сделать свой словарь ,в который сохранять ТОЛЬКО то, что тебе надо. Например, ты не заметил, что у тебя в словаре есть

'entities': [<telebot.types.MessageEntity object at 0x7770137fd0>]

Сюрприз-сюрприз, объект

<telebot.types.MessageEntity object at 0x7770137fd0>

явно сериализации не поддаётся, и ни сохранить, ни восстановить его не выйдет. Или убирать ключ entities, если он тебе не нужен, или разбираться, что это за объект и сериализовывать/восстанавливать его вручную.

Потому что Windows изначально строился на другой идеологии - что приложения пишутся как законченный продукт. И допускается его изменение только автором программы. Поэтому установка осуществляется скомпилированным файлом ехе, в который пользователю лазить не надо.
В NIX-подобных системах все было заточено на opensource и на online работу. Поэтому и появились репозитории, где исходный код, который надо собрать самому под конкретную систему, потом в них добавили apt, т.е. поддержку пакетов, сконфигурированных уже под конкретную систему. И это хорошо, потому что установка и обновление конкретных приложений идет не непойми откуда, а из четко понятного места.

А как перебирать-то, чудо?

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

А так - на до сначала построить математическую модель задачи. Понять, на что эта модель похожа. Может, тут граф нарисовать можно? Какие алгоритмы на графы вы вообще знаете? Применимы ли они тут? Или это строка. Какие есть алгоритмы на строки? Смотрите еще ограничения. По ним обчно понятно, что тут нужно что-то за O(n), или за O(n log n) написать. Множество применымых алгоритмов еще больше уменьшается.

В задачах на оптимальность чего-то помогает рассуждение "рассмотрим ответ. Какие у него можно заметить свойства. Можно ли какой-то ответ немного поменять, не ухудшая его?" Так вы получите какое-то свойство, которое можно уже применять для построения ответа. Например в задачах на жадность так можно понять, что надо отсрортировать что-то.

Потом, очень частая тема - ДП. Попробуйте параметризировать задачу. Свести ее к подзадачам. Формализуйте ДП (считаем вот такую вот функцию от вот этих вот параметров вот с таким вот физическим смыслом).

зашитая в кнопку команда объектом энтри игнорируется

Ты в обработчике кнопки сам создаёшь новый экземпляр класса Put_Entry (который является виджетом), нигде его не размещаешь, а просто что-то с ним делаешь. Конечно, уже существующие экземпляры от этого никак не изменяются - твоя кнопка про них ничего не знает и никак их не трогает.

Короче, читай учебник, для начала. У тебя, похоже, полнейшая каша в голове. Разбирайся в понятиях области видимости и времени жизни, для начала - тогда будет понятнее, что где хранить и что куда передавать.
Не говоря уже о том, что я тебе уже два раза показывал, как хоть немного правильно создавать свои UI-классы, но как об стенку горох.

Сейчас код сначала получает текст, содержащий координаты точек из буфера обмена, потом разбирает и проверяет каждую строку и переспрашивает нужна ли она, а потом уже входит в цикл while True, где он их прокликивает и ожидает нажатия w или q.
Нужно всю ту часть, где определяются координаты, а также сам код прокликивания внести внутрь ветки w.

Как именно - спрашивай у того, кто написал код.

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

Стандартная балалайка - автоматизация существующей инфраструктуры, переход от накликивания руками к IaaC, Terraform, Ansible, CI/CD с линтерами, автоматический деплой на тест/стейдж/прод и всё такое.

Ну для начала что значит "атака"? Какую угрозу ты ожидаешь? Потому что ответы будут ОЧЕНЬ разные в зависимости от этого.

IP бота можно будет попробовать узнать, если ты знаешь, что бот проходит по ссылкам, которые ты можешь ему отправить. Тогда, скинув боту ссылку на свой сайт, можно будет посмотреть, какие адреса заходили в этот момент.
Если бот такого не делает, то скорее всего никак.

Зафлудить бота запросами? С одного аккаунта не получится, а с многих - недёшево. Кому ты нужен за такие деньги?

Потыкать команды бота на пример SQL-инъекции? Если бот вообще использует БД, достаточно использовать стандартные средства подстановки параметров в запросы, а не колхозить SQL чере зформатирование строк.

Угнать бота? Не пости его токен никуда. Если хранишь исходный код в какой-то системе хранения версий - храни токен в отдельном файле и добавь его в исключения. Если есть подозрение, что токен уже уплыл - меняй его у BotFather. А угон акка разработчика - это другая песня уже.

Короче, ответь хотя бы для себя на вопросы:
1. чего конкретно боишься?
2. кому конкретно ты нужен?