Сергей П

https://www.google.com/search?q=tkinter+bind+butto...

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

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

В любом случае звук - это массив чисел длинной Частота_дискретизации*Длительность.
Этот массив можно обрезать по тишине слева и справа, выровнять по уровню, оценить поместится ли в оставшийся фрагмент искомый звук. Потом нужно понимать, что оставшийся массив - это многомерный вектор. Он указывает в некий объём многомерного пространства. Какие-то сати этого пространства "похожи на некий образцовый звук", а какие-то нет. Нужно написать функцию, принимающую вектор и возвращающую число - степень похожести звука на образец. Это делается нормированием.

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

Изучать нужно по теме "Цифровая обработка сигналов", "сравнение звуков"

Всё правильно вам подсказали, надо изменить порядок декораторов, они коммутативны.

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

Посмотрите внимательно на содержимое цикла. Там условие выхода из цикла привязано к счетчику, а счетчик увеличивается только при некотором условии. Другими словами, если случилось так, что это условие неверно и вы в цикле, то счетчик не будет меняться и проверка условия будет молотить вечно, ведь ничего не меняется. Так получается бесконечный цикл.
Вообще такие вещи лучше описывать параметрически. То есть можно описать функцию, которая возвращает координату абсолютную от времени.
Обычно это делается так. Описывается класс, потомки от которого будут описывать характер движения. Паттерн называется "Стратегия".
У персонажа есть состояние, например "равномерная ходьба". Это состояние определяет стратегию движения. То есть когда началась равномерная ходьба, создаётся инстанс этой стратегии, который запоминает время начала ходьбы, начальные координаты и определяет скорость. У стратегии движения есть метод, который возвращает координату от абсолютного времени. Под капотом из этого времени вычитается время начала движения, а потом по простой линейной формуле можно вычислить координату персонажа на любое заданное время. Как только состояние персонажа сменяется на "Рывок", создаётся новый инстанс новой стратегии под названием "Рывок". Она определяет внутри другую функцию вычисления координаты от времени. Скорость тоже может быть задана функцией внутри реализации стратегии.

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

И как вы предлагаете провести аудит вашего кода без публикации этого кода?
Не понятно же что и как вы там храните в памяти.
Правильная архитектура и логирование легко позволяют отслеживать и находить утечки памяти. Часто потенциальные места видно по коду. Я так понимаю кроме утечек памяти у вас там не мало и других проблем, например ненадежное хранение состояния длительных процессов в случае перезапуска сервиса.
Если правильно построить архитектуру вашего сервиса и использовать персистентные хранилища (например БД) для промежуточных состояний, то даже утечки в сторонних внешних библиотеках для вас не будут проблемой, поскольку вы всегда можете ограничить ресурсы и безопасно перезагружать сервис на любом этапе его работы при недостатке памяти.

А вы пробовали искать на гитхабе или в гугле прежде чем сюда приходить? Ну вот например https://pypi.org/project/xkcdpass/
Обычно делается алгоритм, который составляет грамматически верное предложение из рандомных слов. Слова берутся из словаря, где они определены по частям речи. Входной хеш используется в качестве сида для фиксированного алгоритма генерации псевдослучайных последовательностей. Этот алгоритм на базе сида выбирает по очереди слова для шаблона из словаря. Что может быть проще?

Ошибка тут F:\pythonProject\parcer_tg\parcer_functions.py

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

В общем случае эта задача не решается на 100% по определению.
Вы говорите, что вокруг фамилий у вас произвольный текст, а это значит, что среди этого текста попадаются слова, которые чем-то похожи на ФИО, но не ФИО, или имя отчество, без фамилии, или что-то вроде "светкин василёк Игоревич". Можно это считать таким экзотическим ФИО, или отчество тут просто отдельно стоит и искать его не надо?
В любом случае схема решения примерно такая. Если у вас есть знаки препинания, то можно разбить по ним фрагменты текста, ФИО не разделяется знаками препинания (кроме дефиса), но дефис отличается от тире пробелами по бокам.
Далее у вас есть цепочки слов. Если в цепочке N слов, то в ней, можно сказать, N-2 кандидата на ФИО.
Каждая трока-кандидат на ФИО может быть проклассифицирована по ряду признаков, свидетельствующих в пользу того, является ли эта тройка ФИО. Осталось только определить набор признаков и веса этих признаков. Каждый признак определяет два показателя: 1) насколько этот признак добавляет шансов тройке быть ФИО; 2) на сколько несовпадение по этому признаку отнимает шансов быть ФИО. Показатели определяются от нуля до 1 и перемножаются. Подбор признаков и их показателей будет настройкой вашего классификатора.
Тут дальше можно двигаться разными путями.
Часть детектов вы сможете надёжно определять по окончанию отчества.
Часть признаков у вас будут словарными словами, которые, по вашему, не могут быть именем и\или фамилией.
На этом этапе уже будет довольно хорошая детекция. Вопрос что вам важнее, отсутствие false positive, или отсутствие false negative.
Так же по-разному может повезти с входными данными. Если у вас много "ловушек" в виде разбросанных по тексту бесхозных отчеств, если у вас много очень странных имён... в общем тут вам никто не выдаст идеальное решение. При отсутствии четкого ТЗ результатом будет расплывчатое ХЗ.
В целом обычно на настройку таких классификаторов под текст на первое время сажают людей. У нас сейчас есть ChatGPT и ему, думаю, вполне можно скидывать наборы имён, чтобы он вычеркивал те, которые вряд ли именами являются. Если вы приняли, что какое-то слово не может являться именем, или фамилией, то такое решение хорошо бы кэшировать, а затем для консистентности придерживаться аналогичного в других случаях.

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

Конечно. Вот этот цикл совершенно не имеет никакого смысла:

for i in range(len(t)):
    tl.append(t[i])

Третий цикл тоже не нужен. Вы всё можете делать в одном цикле.
Или это вы разрешения спрашивали? Никто не запрещает.

Ну так не вызывайте эти функции, просто указывайте, а вызывайте одну, которую получите из словаря этого. Учить питон надо старательнее. Функция - это объект первого рода в питоне. Функцию можно присвоить в переменную, передать в аргумент.

Ваш подход вполне пригоден к использованию и его можно применять.
Тут надо внести ясность, что есть разница между константами и настройками. Настройки предполагается менять, их иногда "перекрывают" через параметры командной строки или переменные среды окружения.
Если вам нужны настройки, то этот вариант не годится. Используйте предложенный выше вариант с Pydantic.
Если это именно константы, их не потребуется или не скоро потребуется перекрывать, загружать из файлов, пробрасывать через переменные среды окружения, через параметры командной строки и т.д.
Если значения этих констант приемлемо хранить в репозитории, то нет ничего плохого в том, что вы группируете константы в классы. Это нормально для питона.

Но учтите, что вам может захотеться хранить в таких вот местах какие-то чувствительные, т.н. секретные данные. Например, ключи шифрования, пароли для подключения к БД или другим сервисам, ключи API, всякие токены и т.д. Такие данные опасно, неудобно и неправильно хранить в репозитории вместе с кодом. Для хранения таких параметров тоже нужно использовать библиотеки для хранения, сериализации и десериализации настроек.

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

Скорее всего вы применяете клиентское API телеграма не по назначению или вопреки лицензии. Например, вы, может быть, рассылаете спам, или скам, а может быть делаете что-то ещё, что противоречит добросовестному использованию сети.
Конкретной причины, по которой вас блокируют вам никто скорее всего не скажет. В таких случаях самое эффективное - это максимальнео расплывчато описывать причины и критерии возможных блокировок, чтобы играясь с пороговыми критериями злоумышленники не могли подстроиться под ограничения.

Скорее всего ограничения и критерии, по которым вашу деятельность пресекают, не заключаются в чем-то одном. Скорее всего критериев много и они не однозначно влияют на принятие решения о блокировке. Другими словами, если быть по ту сторону баррикад от вас, то причины блокировок нужно сделать максимально многофакторными, диверсифицированными, неявными и нечеткими. Где-то нужно даже вводить рандомизацию и отложенную блокировку, если вы предпринимаете серьёзные меры, чтобы ваш софт притворялся валидным штатным клиентом. В вашем же случае, видимо, паттерн использования протокола и АПИ выдаёт вас мгновенно.

Подумайте чем ваш "клиент" телеграма отличается от добросовестно выполненного клиента для штатных целей? Может быть он не сохраняет контактов? Может быть коннекты идут из одной подсети и она уже "на особом счету"? Может быть На ваши сообщения много жаловались, и теперь отдельные специальные эвристики вылавливают клиентов, похожих по паттерну на ваши и банят их сразу же?

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