Месиво кода без отступов читать не стал, но я бы наверное вообще не стал жестко привязывать корзину к юзеру на уровне кода. Пусть привязывается к сессии и только если юзер залогинен, то к нему. И отношения между юзером и корзиной сделал бы one-to-one, кстати говоря.
devdb, Джанго, допустим, это не CMS, хотя на нем можно написать CMS, разумеется. Никакой структуры данных в нем нет в принципе. Посмотрите документацию, очень мощный и гибкий фреймворк, хотя может показаться громоздким по сравнению с тем же Flask. Зато есть встроенная ORM, что заметно облегчает работу с СУБД.
Вообще если предполагается доступ большого количества пользователей через браузеры, то прога все-равно должна будет крутиться на сервере, а не локально на вашем десктопе. И тут намного проще, мне кажется, переделать ее под какой-нибудь готовый фреймворк, умеющий взаимодействовать с веб-серверами, поддерживающий аутентификацию, сессии, куки и черта с дьяволом, чем фактически писать свой мини-сервер.
Как вариант еще можно выделить "ядро", отрабатывающее бизнес-логику и сделать REST-API для передачи данных (на чем-то вроде FastAPI, например). И отдельно уже сделать на htlm/JS фронт, который будет с этим API взаимодействовать. Тогда все сильно упростится и не нужно будет самому писать низкоуровневое взаимодействие.
React не обязателен, кстати говоря. И если приложение для торговли, а не просто курсы показывать и графики рисовать, лучше взять что-то нативное для разработки.
Данила Смирнов, а не может такого быть, что от старых экспериментов в базе осталась таблица users с _двумя_ столбцами вместо трех? Тогда надо просто ее дропнуть и заработает.
Алексей, это не совсем правильная логика. Правильная логика говорит нам, что в сообщении об ошибке интерпретатор Питон честно сообщает, что lines это список (list) и метода replace у него нет от слова "совсем", а значит вызывать этот метод нужно у какого-то другого объекта...
Вы знакомы с основными типами данных в Питоне и тем, как с ними нужно работать? Если нет, то лучше даже не пытаться разбираться с чем-то более сложным.
Тут главное: нужны ли эльфы в домиках, как известно. И корованы.
В такой формулировке как сейчас это вообще не вопрос. Как говорится: "чтобы задать правильный вопрос нужно знать половину ответа", а автор, похоже, еще ее не знает. Поэтому и спрашивает про совершенно не связанные друг с другом вещи, например canvas (часть механизма отображения информации) и "большой мир" (собственно набор данных и механизмы их изменения).
Самый очевидный вариант: поднять базу на сервере, сохранять туда а в приложении отслеживать обновления. Конкретные детали уже зависят от приложения, так невозможно сказать.
Jekson, я бы не стал в валидатор лезть ради такого. Тем более, что если будешь потом валидировать перед сохранением , то надо чтобы работало как положено. Проще действительно сделать текстовое поле и взять из него данные.
Когда-то очень давно мне нужно было смоделировать технологическую линию и сделать это достаточно гибко. Причем на ЛИСПе. Тогда я решил проблему описания пути заготовок через этапы производства через механизм сообщений. Объекты, представляющие собой единицу технологического процесса (штамповка, окраска, сварка и т.д.), передавали между собой сообщения-заготовки. Соответственно, вся логика обработки была локализована в каждом объекте. Он мог принять сообщение, мог отказаться (если еще не завершена обработка предыдущего), мог перенаправить. Соответственно, если объект принимал сообщение, то дальше уже по своим внутренним правилами генерировал новые сообщения (скажем, лист стали мог превратиться в дюжину вырубленных заготовок) и потом пытался отправить их дальше согласно таблице маршрутизации (точнее, списку маршрутов, так как это все-таки был ЛИСП :)). В итоге все работало красиво и слаженно как оркестр и можно было наглядно видеть где оборудование простаивает, а где копится невыполненная работа.
Возможно, в вашем случае можно сделать что-то похожее.
Aleksandr231224, когда мне нужно было сделать сайт-интерфейс БД я сделал просто:
1. Загуглил "разработка сайта Python" (потому что на Питоне мне писать проще всего), узнал, что есть такие штуки, как Flask и Django.
2. Пошел на Ютюб смотреть видео на тему "Чем отличается Фласк от Джанги".
3. Понял, что у Django есть нормальная ORM (найс), продвинутые шаблоны (огонь!) и встроенная админка (оргазм!) и переключился исключительно на каналы по Django.
4. Параллельно начал писать код на базе увиденного.
5. Насмотревшись, перешел на чтение документации и разбор примеров кода.
В итоге через 2 недели получил работающий сайт с REST API впридачу. Да, внутри местами говнокод, да, выглядит он большей частью стремно, но есть работающая основа, которую теперь можно допиливать в спокойном темпе. Плюс, прокачался новый скилл: "Веб-разработка на Джанго" :).
Поэтому странно читать, что человек, владеющий таким набором инструментов ("JS, PHP, C#, HTML и CSS") не может нагуглить как собрать на их базе прикладной проект.
Soul1, тут явно не нужен полный перебор. Самый правильный вариант, наверное, разобраться в алгоритмах факторизации и разложить число на простые множители эффективным образом. Самый "инженерный" это взять таблицу простых чисел от 1 до корня квадратного из целевого числа и факторизовать наше целевое число с ее помощью. Идем с конца таблицы, делим целевое число на все эти числа по очереди, если результат получается целым числом, то пытаемся рекурсивно факторизовать таким же макаром получившееся частное. Хотя я не уверен, что использование таблиц простых чисел считается "хорошим" решением в этом проекте :).