Максим Припадчев

Идея простая.
Асинхронные приложения - это набор пар "операция - обработчик", где операция - это некоторый длительный процесс (скажем, вводы/вывод), который не требует постоянного внимания со стороны кода. Когда операция завершается, выполняется её обработчик. Этот обработчик может планировать другие операции, и так далее.

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

Соответственно, await-вызов сохраняет текущий контекст корутины, и планирует новую длительную операцию. Какую - зависит от того, что идёт после await. Эта операция представлена тем или иными awiatable значением (Future, Task и т.п.).

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

Ключевой момент - выполняет обработчик, а только потом проверяет остальные операции. Т.е. если обработчик планирует операцию через await - это не проблема, она будет выполняться наравне с остальными. А вот если обработчик просто делает что-то длительное, он не возвращает управление циклу, и не даёт выполняться остальным операциям.

asyncio.sleep() планирует ничего не делающую операцию, которая завершится успехом через заданное время. Поэтому её выполнение не мешает циклу-реактору. Просто ещё один await вызов, который приостанавливает текущую корутину и возвращает управление реактору.

time.sleep() ничего не знает о реакторе и асинхронных операциях. Она приостанавливает выполнение обработчика, не прерывая его и не отдавая контроль реактору. Поэтому на время time.sleep() (или любой длительной синхронной операции) спит вся программа.

Поучи язык. Просто поучи, без ботов.
def объявляет функцию, но не вызывает её.
Ты её объявляешь внутри record_volume(), но ничего с ней не делаешь.

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

Если ты продаёшь в убыток, то маржинальность будет отрицательной, но не меньше, чем -100%

s = [10,
-5,
-2,
-1,
6,
3,
0,
-2,
-2,
-3,
-3,
0,
5,
8]

ss = []
window = 2
for _ in range(0, len(s)-2):
   window += 1
   frame = s[window - 3:window]
   ss.append(sum(frame))

mi = ss.index(min(ss))
slice = s[mi: 3 + mi]
print(slice)

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

insert into message(9999999, -1, "Mua-haha...");

И у меня есть пост от анонимоса который не зарегистрирован как пользователь.

Разумеется можно полагаться на логику твоего приложения и думать что такая ситуация невозможна
но с точки зрения БД она вполне возможна потому как родственная связь User + Message нигде не объявлена.
И SQL позволяет это сделать.

Чтоб поправить ситуацию надо эту связь добавить и тогда я не смогу создать фейковые посты от анонимосов.

ALTER TABLE Message
ADD FOREIGN KEY (userid) REFERENCES users(id);

По умолчанию констрейнт создается с опцией restict (это было в Оракле как в Майскл - не знаю)
и это гарантирует что невозможно также удалять родительские записи пока есть дочки.
Для скорости ссылочные ключи всегда - индексированы.

Рассуждать на тему вреда от аномалий - это просто терять время. Каждый владелец БД сам решает
какие уровни строгости ему вводить. Вообще любая теория касаемая БД - по сути просто развивает
идею строгости НФ1,2,3,4,5,6 и ссылочных ограничений.

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

По сути вопрос сводится к тому как не создавать мусор в БД.

1. Как проверял? Просто пытался угадать? Рандом - штука такая, могло просто не везти.
2. Если пользователь с первого раза введёт правильный key, условие цикла сразу будет False, и цикл не выполнится - а значит, не выполнятся и ifы.

Я бы посоветовал сделать так:

max_tries = 5  # число попыток
key = -1  # заведомо некорректное значение
for i in range(1, max_tries+1):
    key = int(input(f'Попытка №{i}: '))
    if key == lock:
        print(f'Угадал c {i}-й попытки!')
        break
else:  # этот else относится к for! 
    # он выполнится, если for НЕ БЫЛ прерван по break
    print('Попытки кончились. =(')

Спорим у вас винда?
Прочитайте спецификацию функции open. В частности про параметр encoding.
Когда записываете текст в виде байтов (а в файлах он именно так хранится), то нужно понимать какой кодировкой вы кодируете не ascii-символы.
Вы явно не указываете кодировку, поэтому выбирается кодировка по умолчанию. Посмотреть что у вас там по умолчанию можно вот этой фунцией sys.getdefaultencoding()
Именно в такой кодировке нужно открывать ваш файл на чтение, чтобы увидеть там русские буквы.
В винде у вас скорее всего одна из двух кодировок там может быть. И она разная в зависимости от того в консоли вы запустили свою прогу, или в IDE. А ещё подстава - в винде по умолчанию однобайтовые кодировки, поэтому не все символы можно в них представить!
С этим в линуксе гораpдо лучше. По умолчани везде utf-8.

Вот, кстати, можете проверить что получится для понятности:

> 'íåæèëîãî'.encode('latin1').decode('cp1251')
'нежилого'

from sqlite import db_start, create_profile, edit_profile
from main import balance

main импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который импортирует sqlite, который импортирует main, который ...
Ну ты понял.

Быстрого волшебного решения тут нет. Разбирайся с областями видимости, избавляйся от глобальных переменных.
Например, почему у тебя при создании нового профиля используется balance? Т.е. новый пользователь получает столько денег, сколько было у последнего активного?
Почему вообще у тебя вещи, специфичные для одного пользователя, лежат то в глобальных переменных, то в данных машины состояний (state)? Бери их из БД , когда они потребуются.

Просто укажите True в значении нужного атрибута, если ожидаете, что он должен присутствовать у элемента:

from bs4 import BeautifulSoup

document = """<tag a="1" b="2"/>
<tag a="2"/>
<tag a="3" b="4"/>
<tag a="4"/>
<tag a="5"/>
<tag a="6" b="6"/>
"""
soup = BeautifulSoup(document, 'html.parser')
for element in soup.find_all('tag', b=True):
    print(element.get('b'))

Документация: https://www.crummy.com/software/BeautifulSoup/bs4/...