mayton2019

Обычно при улучшении (рефакторинге) ставятся две разных задачи. Первое - это улучшение читабельности кода.
И второе - это улучшение производительности (пропускной способности или времени отклика).

Это две задачи на каком-то этапе противоречат друг другу. Есть график (кривая Шипилева) который это демонстрирует.

По математики не силен ((

Не переживай сильно. Для 80% современных задач разработки тебе понадобиться только школьная математика.
Сложить умножить и процент посчитать. Всё остальное - технический дискурс что делать и как делать.

Высокая наука ушла в области datascience, AI, quantum-computing, и всякие формальные логические (тьфу) системы где теоретики занимаются онаниз.... эээ короче фигнёй страдают.

Что тебе понадобиться на самом деле. Структуры python. Библиотеки. Основы мульипоточки. Работа с файлами и сетью. Там не бох весть какая наука. Школьники разбираются. Вот... тут каждый день кодят дискорд и телеграм ботов.

Еще обрати внимание на операции со строками. Строки - основа современного бизнес-кода. Сравнение строк. Подстроки. Замены. Поиск по регулярке. Это должно быть выучено как молитва. Очень часто программист хорошо умеющий работать со строками выкрутится из любой ситуации. Распарсит json и так далее вручную.

Похоже автор занимается расчетом простых чисел.

Значить так. Четные числа - всегда - составные. Поэтому их можно даже не проверять и сразу прыгать по нечетным 3,5,7....

Внутренний цикл не надо делать от 2 до i. Делитель 2 мы уже исключили выше. Поэтому начинаем с тройки и гоним не до n а до квадратного корня из n. Или наоборот возводим в квадрат. Тут надо понять что для Python быстрее будет. Я на С++ делал там по другому.

Для более глубокой оптимизации все найденные простые - пишутся в array и участвуют во внутреннем цикле как делители. Это еще быстрее.

Этож не Хаскель. Значит можно.

Python вроде только tuples запрещает мутировать. Мне кажется что тут более важный вопрос о конвенции. И о том как на это смотрит команда разработки. Если команда договорится что не мутировать сущности а создавать копии - то делайте так.

У тебя - типичный csv файл. И не нужны тебе там никакие скобочки и двоеточия. Делай проще.

101; 657; 821; 622; 843
102; 696; 874; 709; 1000

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

Не напасёшся регулярок на все фантастические форматы времени.

Ты вот уточни ты чаще хочешь распознать ложное время или пропустить верное?

Я вот вижу что 3 позитивных кейса где время распознано - состоят просто из 2-3 чисел разделенных просто символами.

сейчас 16 часов 26 минут
9 час 10 минут
4 часа 3 часа 22 минуты

Вот просто взять

\d+....\d+....(\d+)? и

и гнать это по всему тексту. Ложные срабатывания отпадут дальше по конструктору объекта дата-время.

Медиафайлы - это очень широкое понятие. Надо уточнить. Но для сбора информации о картинках можно брать библиотеки поддержки exif https://pypi.org/project/exif/

С помощью exif можно излвлекать из jpg картинок информацию о размере. И возможно о устройстве которое фоткало. Может гео-координаты если таковые писались. И прочая техническая инфа.

before_gray = cv2.cvtColor(before, cv2.COLOR_BGR2GRAY)
after_gray = cv2.cvtColor(after, cv2.COLOR_BGR2GRAY)

Вот красавец. В базисе серого цвета идет сравнение.

А если я радугу буду сравнивать? Твой-же алгоритм слепой в этом смысле.

Ну ты почти все правильно написал. Только лишний кастинг не нужен.

if isinstance(message.text, int):

Дело в том что рынок "машинного обучения" сильно перегрет. Каждый newcomer решает любую задачу маш-обучем даже если ему надо сложить 2 + 2. Я не шучу это действительно так. Доходит до смешного. Там где нужен фильтр низкой частоты или расчет арифметического среднего все пытаются втащить методы которые на два порядка сложнее и энергозатратнее.

По поводу вопроса. Допустим ты играешь в PacMan (желтый колобок который кушает белые точки на черном фоне) и ты хочешь просто найти пакмана - то тебе достаточно к примеру уменьшить размер экрана в 32 раза и тогда колобок станет размером в 1 пиксел (я предполагаю что он был размером 32 на 32). При усреднении цвета - брать max. Между черным и желтым - всегда выбирать желтый. Далее после того как колобок найден на мелком поле - и известны его координаты - можно двигаться в обратную сторону увеличивая масштаб. И за 5 итераций найти точные координаты ПакМана. В моём алгоритме вобщем-то нет никакого opencv. И я утверждаю что мой алгоритм менее ресурсоёмок чем все прочие подходы.

Впрочем это - просто идея. Ее можно бесконечно упрощать или улучшать. Возможен кейс когда враги скушали пак-мана и он будет плохо распознан моим методом. Вобщем есть огромное пространство для фантазии и алгоримизации без машинного обучения.

Это не будет работать. Последнее несколько чисел в номере карты - контрольные. Они страхуют ввод номера карты от опечаток. Посмотри что такое алгоритм Луна.

И первые несколько цифр показывают обычно код банка и код платежной системы (Viza, Maestro). Нагуглишь сам.

У Python 2.x, 3,x были разные формы представления числа типа int.

Поэтому я бы выбирал тот тип данных который даёт arbitrary precision.

Разумеется плавающая точка здесь не помощник.

Есть много способов устроить нагрузочное тестирование. Как вариант - приложение JMeter https://jmeter.apache.org/

При чем здесь Wifi - непонятно. Обычно тестируют приложение а не частные куски сетей.

Техно-стек Erlang/OTP считаеться эталлоном надежности. Акторы. Супервизоры.

Вот изучи новый язык. Хорошая мотивация уже есть :)