Сергей П

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

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

Вы сейчас концентрируетесь на отправке трека в реальном времени, а попробуйте детектировать ситуацию на маршруте по динамике изменения координат и по данным с акселерометров. Можно сделать блок, который будет голосом объявлять остановки, показывать на мониторе динамическую мини-карту маршрута, делать прогнозы прибытия на ключевые остановки... Конечно это в большей степени backend-задача.

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

Если тема транспорта не сильно принципиальна, но GSM и GPS ваша тема, то могу предложить идею ПРАВИЛЬНОГО детского телефона-трекера.
Все эти смарт-часы у детей живут от силы пару дней от батареи, а в остальное время лежат разряженные и забываются перед любым выходом из дома. Нормальный детский трекер должен быть как тамагочи, то есть грамотно и вовремя напоминать ребенку о необходимости зарядки, о том, что нужно подойти к окошку, если давно не ловились спутники, о том что его ищут родители. Нет смысла трезвонить о низком заряде, если ребёнок не дома или таскает прибор в кармане. В этих случаях нужно уйти глубже в энергосберегающий режим, чтобы хоть реже, но по-прежнему бесперебойно и регулярно отправлять на сервер сведения о статусе. Тревожная кнопка должна быть эффективной и надёжной, а прибор должен уметь сам после безуспешного обзвона по кругу аварийных номеров родителей дозвониться в 112 и внятным голосом робота зачитать в линию координаты и имя ребёнка, контакты родителей и проиграть звуки, записанные при последней активности вокруг устройства.
Девайсу нужны крутые сменные панельки и набор stl-шаблонов для кастомизации с помощью 3д-принтера. Девайсу нужна "уютная кроватка" - кредл для зарядки. Девайсу, лежащему в рюкзаке, висящему на ключах или верхней одежде, нужен дополнительно лёгкий браслет с кнопкой и радиолинком. Такой браслет - это выносная тревожная кнопка, способ быстро найти сам девайс, удаленно мониторить состояние, температуру и шевеления ребенка, а также его удаление от Трекера. Спроектируйте такой трекер в форм-факторе брелка для ключей и чтобы жил от заряда месяц с регрессией частоты выхода на связь и это будет крутой социально значимый проект. Если вы умудритесь добавить в трекер еще и аварийный коротковолновый радио-маяк, то дети с таким прибором не будут безнадёжно теряться в лесу.

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

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

1. Проанализировать регулярки, найти зависимости и "скомпилировать" их в одну регулярку или небольшую группу из нескольких. Обрабатывать регулярки можно эвентуально. То есть дополнительно анализировать матчи программно и в зависимости от контекста подставлять соответствующую замену. Ещё можно пир компиляции регулярок в одну поименовать группы уникально так, чтобы по имени проматченной группы можно было найти нужную замену в словаре замен.
   
2. Если замены более-менее однотипные, например одни теги заменяются на другие, то можно вообще построить общую универсальную простую регулярку на тег, а программно смотреть по словарю чему соответствует матч и делать нужную замену.
   

Эти оптимизации позволят сделать замены за число проходов, которое не кратно числу регулярок, которых много. В идеале за один проход.

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

Ну вот объясните, или это тут надо отдельным вопросом задавать?
Почему я нашел готовое разжеванное решение прямо по формулировке вашего вопроса в гугле в виде ссылки на отличную подробную статью?
https://habr.com/ru/post/81532/
Почему я нашел, а вы нет?

В питоне строки - это объекты и у этих объектов есть встроенные функции (называются они "методы").
Так вот, у строки есть такие методы:

> '1234567'.isdigit()
True
> '123.45.67'.isdigit()
False
> '1234567'.isalpha()
False
> 'Smith'.isalpha()
True

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

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

Я отвечу чуть более развёрнуто.
Дело в том, что float хранит дробные числа в двоичном формате.
Кроме двоичных мы работаем с десятичными числами и тут возникает проблема.
К примеру, число 1/3 (одна третья) в десятичной системе счисления будет записываться как бесконечная (периодическая) десятичная дробь 0.33333(3). А вот в троичной системе счисления это число запишется конечной троичной дробью: 0.1 (читается, как "ноль целых и одна третья").
По такой же схеме у нас десятичное число 0.5 (ноль целых и пять десятых) равно в двоичной 0.1 (ноль целых и одна вторая). 0.25 [10] == 0.01 [2]; 0.75 [10] == 0.5 [10] + 0.25 [10] == 0.11 [2].

А теперь, внимание, на десятичное число 0.2 (ноль целых и две десятых), для перевода в двоичную систему счисления нам нужно сложить это число из членов двоичного ряда:

==1/2, 1/4, 1/8, 1/16, 1/32, 1/64, 1/128, 1/256, 1/512, 1/1024 ...
0. 0    0    1    1     0     0   ( 1      1      0      0 )

В круглых скобках обозначен период двоичной дроби. То есть двоичной дробью в конечном количестве знаков после двоичной запятой задать десятичное число 0.2 (ноль целых и две десятых) НЕЛЬЗЯ!

Если у нас есть лишь конечное количество знаков, то ими представить в точности 2/10 в двоичной системе счисления одним числом невозможно.
Чему конкретно получится равным "обрзанное" (округлённое конечно) число будет зависеть от того по какой именно двоичный разряд мы его округлили.

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

Итак, чтобы сравнить два числа на равенство, скажем a и b, нужно выбрать некое e=0.0000001, которое будет определять точность сравнения и проверять условие: abs(a-b)<e - модуль разности сравниваемых чисел должен быть меньше выбранной точности. Если условие соблюдается, то числа считаем условно равными с заданной точностью. Если нет - не равными.

Добавлю, что, как отметили выше, цены и денежные суммы вообще в формате с плавающей точкой хранить "плохая примета"=). Для этого есть специальные форматы, которые не создают таких сюрпризов при переводе из/в десятичную систему.
Вот замечательная статья на хабре про это: Потеря точности из Double во Float или «Куда пропа...
Ну и еще есть: Что нужно знать про арифметику с плавающей запятой, Наглядное объяснение чисел с плавающей запятой, Разбираемся в числах с плавающей точкой, и т.д.

Странно, что имея опыт разработки на других языках вы задаёте такой вопрос.
Если вам обязательно нужна книга, то, вот, прочитайте Луца по диагонали.
Структуры приложений разные для разных применений, но в целом структуру пакета определяет setuptools. Это встроенный инструментарий работы с пакетами.
Оптимальные структуры имеет смысл искать на гитхабе по ключевым словам "project template" и "cookiecutter".
"Тиражирование" модулей через https://pypi.org/.
Для тестирования есть несколько встроенных альтернатив и миллион сторонних. Выбирайте любую. Для начала не важно.

Как вы знаете для Java есть много всего типа maven, а для python есть что-то подобное? Или, так как язык не компилируемый, для него такого не нужно?

Все ваши потребности на первых порах слихвой покроют setuptools, pip, и github пайплайны.
На вашем уровне, наверно, рано лезть глубже. Придёт со временем.

Из IDE: Pycharm (вполне достаточно бесплатной Community Edition) и Visual Studio Code.

Насколько я понял, вас вовсе не bluetooth мышь. Для bluetotth не нужен usb-донгл.
Но ваша проблема скорее всего связана с подсевшими батарейками или старым аккумулятором. Купите свежие алкалиновые батарейки и проверьте: отключения должны пропасть.

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

В QGIS можно сделать самую обычную карту как с нуля, так и взяв куски из OSM.

Стоит ли давать и какие есть варианты защитить код?

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