Dmitry

Здравствуйте! Если Вы используйте метод predict или просто обращаетесь к экземпляру model(), то Вы можете использовать атрибут classes. Он принимает список с id классов, которые будут распознаны.

id классов можно найти в .yaml файле для обучения модели. в случае в датасетом COCO, на котором обучена модель YOLO, которая идет в этой библиотеке, этот файл можно найти по ссылке https://github.com/ultralytics/ultralytics/blob/ma...

from ultralytics import YOLO

# Load a pretrained YOLOv8n model
model = YOLO('yolov8n.pt')

# Run inference on 'bus.jpg' with arguments
model.predict('bus.jpg', save=True, imgsz=320, conf=0.5, classes=[0,1])

#или так
#model('bus.jpg', save=True, imgsz=320, conf=0.5, classes=[0,1])

вот ссылка на документацию https://docs.ultralytics.com/modes/predict/#infere...

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

Варианты:
1. Сесть и нормально разобраться с Django ORM, там очень много возможностей. Так же для работы с ним надо перестать думать уровнем SQL, т.е перейти на уровень взаимодействия между models
2. Либо нанять нормально программиста, он за тебя это перепишет.

VSCode тут вообще не при чём, импорт выполняется в питоне, а не в редакторе кода.
С версии 20.0 модуль Filters был полностью переписан. Подробно читайте здесь:
https://docs.python-telegram-bot.org/en/stable/tel...

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

Нужно ещё понимать, что с какого-то SDK Level приложения больше не могут делать exec и запускать другие приложения соответственно. А с более низким SDK Level больше невозможно пройти review у гугла. Поэтому Termux нынче распространяется через сайт в виде apk-файла, а не из магазина.

А чем Termux не угодил? Всё остальное всё равно никак по фичам не дотягивает.

PS: И да, этот код я сделал благодаря Chat-GPT 4 Turbo

вот его и проси исправить

open core

вот в этом.

пробовал реализовать это через глобальную переменную

да когда вы уже поймете, что вам нужно персистеное хранилище (а глобальными переменные новички вообще пользоваться не умеют), упал твой бот или ты его перезапустил, всё, обнулилась твоя переменная. Используй нормальную СУБД, причем не sqlite, с ней будет проблема, потому что боты работают в конкурентной среде, а тут еще и async

Не читай про мультипроцессинг, читай про asyncio.gather или asyncio.wait :)

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

Однако, переменные окружения имеют ряд недостатков. Когда мы храним секреты в переменных окружения, велик шанс того, что программист будет кидать эти секреты в логи, выводить их в поток вывода при сборке/деплое, хранить их в незашифрованном виде где-то в базе и т.д.

Поэтому, сейчас всё чаще используются специальные сервисы по хранению секретов.
Я вам рекомендую посмотреть, например, в сторону Hashicorp Vault и его Dynamic Secrets:
https://www.hashicorp.com/products/vault

Вот статья об интеграции в Gitlab:
https://docs.gitlab.com/ee/ci/examples/authenticat...

Видео о том, что это такое, и как это работает:
https://youtu.be/VYfl-DpZ5wM?si=SutHlBsLe70qCIVm
На русском: https://youtu.be/-HIy89Vyobg?si=O4e8AL1SSCm8ImV1

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

Во первых, виртуальные серверы не подходят для числодробилок (исключение - использование GPU или других сопроцессоров типа FPGA, там обычно они делятся по честному), потому что физический сервер будет разделен между несколькими пользователями, и даже если ты наберешь тарифным планом максимальное количество процессоров/ядер, часть ресурсов (для серверных - 3-5%, а для десктопных железок до 10-30% в очень специфических случаях) будут тратиться на обслуживание виртуализации.

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

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

Поэтому правильный ответ - процессор мощнее на физическом железе (bare metall) без виртуализации. При необходимости, для своих нужд, ты сможешь на нем запустить систему виртуализации (или лучше паравиртуализации).

p.s. тебе верно советуют, не смотреть на гигагерцы.
Все очень зависит от того как и какая задача запускается. Оптимизация кода, выбор архитиктуры (например 32-битная на 64-битной будет работать по другому, где то хуже где то лучше), глобальные параметры (размеры буферов пакетной обработки, количество запущенных воркеров/потоков, настройки кеширования и тюнинг файловой системы ос или выбор конфигурации хранилища,..). Это вопрос исследования, и только эксперименты могут дать какой то адекватный ответ. Еще раз - тестируй на реальном железе.