Я просто не пойму, почему cursor position игнорирует координаты, которые я ему задаю
проверял через точку остановки, все в порядке

там с ним есть какие то мемы

причем идут не столько из шарпов, сколько из самого "апи" (если так можно скзаать) консоли

Лично я его в меру часто использую. Если исключить питонские динамические замашки, то и нормальные случаи есть.

Вот сделал я сущность Пользователь. Пользователя нужно хранить в БД. Чтобы хранить в БД, ему нужно иметь account_id. Можно и без числового идентификатора, но тогда идентификатором должен быть юзернейм, а если его захочется поменять, то будут большие проблемы. Короче, нужно число. А число можно получить только от БД.

Но с точки зрения архитектуры, создание сущности не должно зависеть от хранения сущности. В AccountRepository не должно быть метода create_user.
Т.е. я не могу создать пользователя с account_id не обращаясь к БД, причём обращение должно быть атомарным, иначе в многопоточной среде если где-то ошибиться, требование id из БД, потом добавление его в юзера, потом запись юзера в БД приведёт к проблемам - либо будут пропущенные id, либо account_id violates unique constraint или чё там с одинаковыми primary_key.

Далее я понял, что сущности Пользователь в предметной области вообще не нужен account_id, потому что account_id имитирует в реляционной парадигме то, что в других местах работает через ссылки, вложенные структуры, списки объектов и т.д.
Соответственно account_id не нужен сущности Пользователь, но нужен таблице пользователь. У сущности Пользователь на уникальность указывает уникальное имя пользователя.

Поэтому в AccountRepository я добавил словарь Dict[username_string, account_id_int].

Я вызываю AccountRepository.add_account(Account), там происходит INSERT с RETURNING account_id, потом account_id записывается в словарь. То же самое с get_account_by_***. Пользователь достаётся из БД и его id записывается в словарь. Словарь приватный для хранилища.

И так я отделил сущность от id, который нужен только БД. И когда я делаю запрос, я пишу не
select ... from post where post.account_id = (select account.account_id from account where account.username = %s), а просто достаю id из словаря и пишу нормальный запрос с where post.account_id = %s.

Короче, я сел на два стула))))

Типа, а как иначе без словаря сделать связь ключ: значение?

List<(T,R)>

))))))))))))))))))))))))))))))))))))

Ну, наверное да..

Чес говоря лень думать даже

Другой вопрос в том, зачем в геймдеве держать пары ключ: значение. Я чёт не могу придумать нормальный случай))).

Может, локализация?

Кординаты пакмена должны быть отдельно
Ты ресуешь карту и сверху пакмена через какой то иф.


Масив с картой не должен загрязняться пакменом ))

Движущиеся объекты отдельно
Тогда и очищать не нада ничего

А иф зачем?

Ну что бы когда дойдешь до места где будет пакман - нарисовать его:)

Ты карту рисуешь же внутри 2 циклов наверное.

И когда доходишл до клетки с пакменом - можно и пакмена нарисовать.

Аа, то есть если я объект нарисую отдельно от карты, то при передвижении пакмэна по координатам "самой консоли" не будет оставаться его предыдущий след?

Да

кхм, спасибо
попробую