Vindicar

В общем случае план будет такой:
1.Берете два листка. На первом рисуете алгоритм работы, который вы описали. Чем подробнее, тем лучше. Для каждого шага сбоку выписывайте какие данные могут участвовать (номер цеха/отдела, статус заявки и т.д.) в этом этапе. Потом на втором листке рисуйте схему базы данных с учетом всех данных с первого листочка. Когда нарисовали - приводите к 3 нормальной форме и идете писать код.
2. Открываете офф. доки и смотрите как написать набор CRUD-операций с фильтрацией и разграничением уровня доступа (чего-то более сложного я не увидел тут).
Подробнее рассказывать не вижу смысла - это форум для решения конкретных проблем формата:

Мне надо Х, я попробовал Y, у меня получилась ошибка Z. Как исправить?

Ну а в текущем случае вам либо на фриланс, чтобы за вас написали, либо в ВУЗ, чтобы разжевали.

Потому что так исторически сложилось.
1. Очень многие механизмы раньше (а какие-то и сейчас) работают только со свойствами, но не с полями.
А если они и умеют работать с полями - часто по-умолчанию они с полями не работают.
(Это относится ко всяким сериализаторам, ORM, и другим штукам, которые работают с объектами через рефлексию, создают прокси)

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

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

По сути всё.
Сказки про инкапсуляцию оставим для учебников, так как если мы делаем какую-то тупую DTO-шку, то никакой пользы от обращения через свойства мы не получим.

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

Те же рекорды (record, record struct) вообще не позволяют тебе объявить поля и при этом скрывают многословность свойств.

к примеру, не сделать этот int отрицательным

На самом деле это очень редкий кейс.
Зачем делать какую-то валидацию, если можно изначально использовать тип, который не допускает отрицательных значений?

но вот смысл автоматических свойств я так и не могу осознать, хоть убейте

Смысл автосвойств - чтобы не писать руками { get {return x;} set {x = value;}}.
А смысл свойств вообще - чтобы можно было вынести в интерфейс, переопределить, итд.

А ещё у свойства я могу не писать set или вместо set написать init и required, чего я не смогу сделать в классе с полями.
Да, у поля можно написать readonly и получить по сути то же самое, но тогда его надо будет обязательно через конструктор инициализировать.

1. Куда устанавливать python Абсолютно без разницы. Главное, чтобы потом не было проблем с путями и админ. правами
2. Куда устанавливать библиотеки Насколько я понимаю, вы новичок в этом деле, поэтому я не советую вам на этом этапе заморачиваться с виртуальными окружениями. Да - с ними правильнее, да - с ними удобнее. Но вам пока можно и без них. Касательно pip. Без разницы откуда вы его запускаете. Хоть из С:\Python311, хоть из C:\Users\MyName. pip устанавливает библиотеки в папку lib/site-packages, которая находится в той папке, где установлен python

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

Сначала общая информация:

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

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

Самым простым вариантом будет заключить запросы между вызовами beginTransaction() и commit(), как показано например в документации к последнему.

$db->beginTransaction();
$db->prepare("UPDATE `tab1` SET `col` = ?")->execute($data1);
$db->prepare("UPDATE `tab2` SET  `col` = ?")->execute($data2);
$db->prepare("UPDATE `tab3` SET  `col` = ?")->execute($data3);
$db->commit();

Для современных версий РНР этого должно быть достаточно: начиная с РНР 8.0 ошибочный запрос по умолчанию выбрасывает исключение. Не пойманное исключение прерывает выполнение РНР скрипта. При прерывании выполнения скрипта РНР закрывает соединение с Mysql, а при закрытии соединения Mysql откатывает все открытые в нём транзакции.

Соответственно, при ошибке в любом из запросов транзакция автоматически откатится. А при успешном выполнении всех запросов транзакция, соответственно, закоммитится.

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

Важно помнить некоторые особенности.

• в mysql не все движки таблиц поддерживают транзакции. впрочем ,учитывая что innodb является движком по умолчанию уже лет 20, это вряд ли будет проблемой
  
• запросы на изменение страктуры таблиц автоматически коммитят стартовавшую транзакцию, то есть их следует избегать. Кажется, в новых версиях какие-то уже не коммитят, но я предпочитаю избегать всё равно.
  

Также желательно помнить, что в любом более-менее сложном коде очень быстро появляются вложенные транзакции, а PDO при попытке стартовать транзакцию при уже открытой, выбросит исключение, что, соответственно, приведёт к откату родительской (и это гораздо лучше поведения MySQL по умолчанию, которая автоматически коммитит старую). И имеет смысл накидать простой кодик, который считает вложенные транзакции, и не стартует, если уже был старт, а при коммите вычитает вложенность, а реально коммитит только если вложенности не осталось. Что-то вроде кода из комментариев к beginTransaction(), подравняв его напильником

class \MyPDO extends \PDO
{
    protected $transactionCounter = 0;

    public function beginTransaction()
    {
        if($this->transactionCounter++ === 0) {
            return parent::beginTransaction();
        }
    }
    public function commit()
    {
        $this->transactionCounter--;
        if($this->transactionCounter === 0) {
            return parent::commit();
        }
    }
    public function rollback()
    {
        $this->transactionCounter = 0;
        return parent::rollback();
    }
}

разместив его либо прямо в PDO, либо в своем враппере.

дергай телеграм бота, простой http запрос

Дело не в цикле for. Функция pair возвращает генератор, а генератор можно обойти только один раз.

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

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

global - это инструкция не о том, где создать переменную, а где искать.

(3).__class__- здесь объект создался, затем ты обращаешься к его атрибуту.

3.__class__ - здесь при его создании произошла ошибка (если быть точным даже на стадии парсинга ошибка), питон пытается спарсить, как float, и у него естественно не получается.

Мануал, опции ФС, первая же строчка: https://github.com/yt-dlp/yt-dlp?tab=readme-ov-fil...

Заведите строку со алфавитом, по которому идёт шифрование, и тогда вам будет без разницы, какие символы и сколько использовать. Если символа нет в алфавите, то оставляете его как есть. Если символ есть в алфавите, то нахо́дите его позицию, добавляете смещение по модулю длины алфавита, находите новый символ в вычисленной позиции.

Как варианты:
1. Обязательно ли искать оранжевый индикатор во всей области изображения, а не в одном ожидаемом месте?
2. mss.mss() - обязательно ли каждую итерацию захватывать экран заново?
3. Преобразование в hsv точно нужно?
4. time.sleep(0.05) # Проверяем цвет каждые 100 мс - что то не клеится в Ваших показаниях, на основание чего указано 50мс?

Короче, профилировщик в зубы и бегом искать узкие места самостоятельно.

Это норма и так все собственно и делают.
И ровно для этого в ютубе по кнопке "поделиться" есть возможность сделать iframe для проигрывания и у самого ютуба в доке описано, как можно сделать из ссылки такой iframe.
Правда есть нюанс:
1. Видео должно быть доступно без регистрации
2. Видео должно быть публичным. (не доступ по ссылке)
3. Не должно быть возрастных ограничений (иначе будет п1)
4. Автор видео должен при загрузке явно разрешить встраивание на другие платформы
5. У видео не должно быть ограничений по странам
6. Сам youtube должен быть доступен в стране, где сидит пользователь)

Типовой способ, каждый кадр все видимое поле очищается и ПОЛНОСТЬЮ перерисовывается, что бы не мигало, делают это в виртуальный буфер, который после этого копируется на экран.

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

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

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