Ну, есть еще одна альтернатива. Не отображать данные в структуру объектов. А сохранять данные в виде, скажем многомрных массивов и их обрабатывать. Ведь вовсе не обязательно всегда и везде работать испольуя только ООП. Оно не всегда хорошо работает.
Както очень надоели поиски виноватых. Родители, школа, вуз. Как по мне, человек уже лет с семи кует свою жизнь сам, а может даже и с трех. С 18-ти полностью отвечает за свою жизнь. Не дали каких-то знаний в школе - пойди и возьми сам. А школе спасибо, за то, что научила читать, писать и таблице умножения. Это утрировано, а то сейчас начноут писать, что читать я уже умел, когда в школу пошел.
И первое, что нужно, перестать ныть, а подумать, что я могу сделать сам.
Еще одна мысль, человек, это такое существо, которое живет в будущем.
Иногда можно пользоваться ORM. Но нужно понимать, что это такое и в чем проблема.
Есть одна неустранимая проблема. Она в характере табличных данных и представлении этих данных в виде объектов.
ОРМ берет табличные данные, тащит их в память, представляет их в виде объектов и дает работать там с этими объектами процедурным образом. Это эффективно для работы с небольшим количеством данных, причем в древовидном виде (объекты/поля, ссылки на другие объекты).
В реляционной базе данных используются данные в виде таблиц и специально сконструированный декларативный язык для доступа к этим данным. Это: 1) эффективно для больших объемов табличных данных. 2) Позволяет встроенными средствами поддерживать целостность и непротиворечивость данных.
Таким образом вы или работаете с запросами БД или тащите данные в память и там с ними работаете. Причем если вы хотите большие объемы и целостность, вам придется реализовывать самому часть функциональности реляционной ДБ.
Поэтому ОРМ не является серебряной пулей. Более того, в неопытных руках это достаточно опасная штука.
Таки не понимаю, зачем всё это, но иначе оно не работает - MX Linux в явном виде запрещает ставить через pip install в систему,
Ну как зачем. В Linux куча всего работает, испольуя Python. Куча мейнтеров и тестеров работает для того, чтобы все было совместимо. Вы ставите пипом в систему какой-то левый пакет, он тащит свои зависимости. И вдруг бах, что-то совершенно другое перестает работать. И Вы ругаете и клянете Линукс. В Виндовс у Вас ничего системного на питон не завязано, можете делать с питоном что хотите.
На Линуксе можно тоже делать что хотите, только систему не трогайте. Ну или если трогаете, понимайте последствия.
Это не геморрой, чтобы избежать бардака только такая система и возможна. - Общесистемные пакеты ставите только через apt. (Если специально не знаете что делаете и зачем) - Пакеты для своего использования ставите в свою домашнюю директорию. Можно просто в домашнюю директорию,
pip install package --user
Пакеты установятся в директории:
/home/user/.local/lib/python3.x/site-packages
- Но я бы и для своего использования создал бы виртуальное окружение и ставил бы в виртуальное окружение, тоже в директории .local. Возможны конфликты версий пакетов зависимостей.
- Для собственных проектов используете виртуальные окружения. Для каждого проекта свое.
По моему все достаточно просто и логично. Нужно только понять систему. Собственно по другому и невозможно сделать без того, чтобы не организовать бардак и конфликт версий.
С Python всё странновато - не даёт ставить ничего через pip install вообще: на уровне системы пакеты ставятся через apt, а для тех, которых там нет, извольте вам завести virtualenv и туда уже ставить через pip.
Только так и должно быть. И это правильно. Иначе сломаете систему. Если не понимаете, что делаете, то ничего в систему ставить руками не надо.
Я конечно тот еще англичанин, но пару минут подумав, решил, что лучше и понятнее сказать что-то вроде: "I will never make plans to get successful." А ChatGPT3.5 подсказывает: "I will never plan to be successful."
Где-то я слышал, не помню где, что при распараллеливании задач возрастают затраты на их синхронизацию. Да еще и многие задачи очень плохо параллелятся.
Вот объясните мне, зачем вообще использовать треды? Ладно, если делать что-то простенькое. Но для серьезных вещей всегда можно взять мультипроцессинг. И никаких проблем с GIL/
Ну, не занаю. Пример в начале статьи не просто плохой, а очень плохой.
И наборот, я бы назвал пример хорошего кода плохим кодом, а хорошего - плохим хорошим. Потому, что при первом взгляде на верхний код однозначно понятно, что он делает и что возвращает, а на нижний - непонятно.
ИМХО, в физике все три категории - пространство, время и движение идут пакетом и разделить их нельзя. Другое дело в математике, там можно отделить пространство от времени и от движения.
ИМХО, периодичные феномены это просто такие штуки, которыми удобно измерять время. Само же время не завязано на них. можно определить секунду, например, как время, за которое свет проходит 300000км.
Попытаюсь пошутить: Пространство это способ существования физических тел.
А если серьеззно, ИМХО, пространство неотделимо от времени. Ну и без движения у пространства-времени тоже нет никакого смысла. Т.е. можно так сказать, что пространство это такая сущность, в которой можно определить движение.
Как-то эти рекомендации выглядят совершенно нереально, особенно там где школа/дерево/дом/сын. Ну ладно, школа, пусть, но вот дерево растет лет 50 и все это время за ним нужно ухаживать. Дом строить это тоже занимает лет 5-10, и сразу по окончанию нужно поддерживать и ремонтировать. Сына растить тоже лет 25-30 нужно. Т.е. для выполнения их рекомендаций нужно 2-3 человеческих жизни.
Почему-то минусуют. А ведь есть такие подходы к архитектуре, как Data-driven design, stream processing и data pipelining.
Ну, есть еще одна альтернатива. Не отображать данные в структуру объектов. А сохранять данные в виде, скажем многомрных массивов и их обрабатывать. Ведь вовсе не обязательно всегда и везде работать испольуя только ООП. Оно не всегда хорошо работает.
Както очень надоели поиски виноватых. Родители, школа, вуз. Как по мне, человек уже лет с семи кует свою жизнь сам, а может даже и с трех. С 18-ти полностью отвечает за свою жизнь. Не дали каких-то знаний в школе - пойди и возьми сам. А школе спасибо, за то, что научила читать, писать и таблице умножения. Это утрировано, а то сейчас начноут писать, что читать я уже умел, когда в школу пошел.
И первое, что нужно, перестать ныть, а подумать, что я могу сделать сам.
Еще одна мысль, человек, это такое существо, которое живет в будущем.
Иногда можно пользоваться ORM. Но нужно понимать, что это такое и в чем проблема.
Есть одна неустранимая проблема. Она в характере табличных данных и представлении этих данных в виде объектов.
ОРМ берет табличные данные, тащит их в память, представляет их в виде объектов и дает работать там с этими объектами процедурным образом. Это эффективно для работы с небольшим количеством данных, причем в древовидном виде (объекты/поля, ссылки на другие объекты).
В реляционной базе данных используются данные в виде таблиц и специально сконструированный декларативный язык для доступа к этим данным. Это: 1) эффективно для больших объемов табличных данных. 2) Позволяет встроенными средствами поддерживать целостность и непротиворечивость данных.
Таким образом вы или работаете с запросами БД или тащите данные в память и там с ними работаете. Причем если вы хотите большие объемы и целостность, вам придется реализовывать самому часть функциональности реляционной ДБ.
Поэтому ОРМ не является серебряной пулей. Более того, в неопытных руках это достаточно опасная штука.
По моему где-то так.
Ну как зачем. В Linux куча всего работает, испольуя Python. Куча мейнтеров и тестеров работает для того, чтобы все было совместимо. Вы ставите пипом в систему какой-то левый пакет, он тащит свои зависимости. И вдруг бах, что-то совершенно другое перестает работать. И Вы ругаете и клянете Линукс.
В Виндовс у Вас ничего системного на питон не завязано, можете делать с питоном что хотите.
На Линуксе можно тоже делать что хотите, только систему не трогайте. Ну или если трогаете, понимайте последствия.
Это не геморрой, чтобы избежать бардака только такая система и возможна.
- Общесистемные пакеты ставите только через apt. (Если специально не знаете что делаете и зачем)
- Пакеты для своего использования ставите в свою домашнюю директорию. Можно просто в домашнюю директорию,
Пакеты установятся в директории:
- Но я бы и для своего использования создал бы виртуальное окружение и ставил бы в виртуальное окружение, тоже в директории .local. Возможны конфликты версий пакетов зависимостей.
- Для собственных проектов используете виртуальные окружения. Для каждого проекта свое.
По моему все достаточно просто и логично. Нужно только понять систему. Собственно по другому и невозможно сделать без того, чтобы не организовать бардак и конфликт версий.
Только так и должно быть. И это правильно. Иначе сломаете систему. Если не понимаете, что делаете, то ничего в систему ставить руками не надо.
Я конечно тот еще англичанин, но пару минут подумав, решил, что лучше и понятнее сказать что-то вроде: "I will never make plans to get successful."
А ChatGPT3.5 подсказывает: "I will never plan to be successful."
Где-то я слышал, не помню где, что при распараллеливании задач возрастают затраты на их синхронизацию. Да еще и многие задачи очень плохо параллелятся.
Я не знаю, на каком языке это написано, наверное псевдокод, но по питонячьему смысл верхнего кода такой:
Проверить, что значением value является логическое True, если да, вернуть логическое True
В любом другом случае вернуть логическое False
Для нижнего кода смысл просто вернуть value.
Таким образом, если скажем значение value например "test_value", верхний код вернет False, нижний код вернет "test_value".
По моему так.
Вот объясните мне, зачем вообще использовать треды? Ладно, если делать что-то простенькое. Но для серьезных вещей всегда можно взять мультипроцессинг. И никаких проблем с GIL/
Ну, не занаю.
Пример в начале статьи не просто плохой, а очень плохой.
И наборот, я бы назвал пример хорошего кода плохим кодом, а хорошего - плохим хорошим. Потому, что при первом взгляде на верхний код однозначно понятно, что он делает и что возвращает, а на нижний - непонятно.
Я бы еще добавил, что REST хорошо подходит для CRUD, что-то немного более сложное на нем делать неудобно.
ИМХО, все (ну пусть не все, но многие) начинают делать REST, а в конце-концов получается RPC.
Но ведь периодическое движение это просто частный случай движения вообще. Или нет?
ИМХО, в физике все три категории - пространство, время и движение идут пакетом и разделить их нельзя.
Другое дело в математике, там можно отделить пространство от времени и от движения.
"ping me" ?
ИМХО, периодичные феномены это просто такие штуки, которыми удобно измерять время. Само же время не завязано на них. можно определить секунду, например, как время, за которое свет проходит 300000км.
Попытаюсь пошутить: Пространство это способ существования физических тел.
А если серьеззно, ИМХО, пространство неотделимо от времени. Ну и без движения у пространства-времени тоже нет никакого смысла.
Т.е. можно так сказать, что пространство это такая сущность, в которой можно определить движение.
Как-то эти рекомендации выглядят совершенно нереально, особенно там где школа/дерево/дом/сын. Ну ладно, школа, пусть, но вот дерево растет лет 50 и все это время за ним нужно ухаживать. Дом строить это тоже занимает лет 5-10, и сразу по окончанию нужно поддерживать и ремонтировать. Сына растить тоже лет 25-30 нужно. Т.е. для выполнения их рекомендаций нужно 2-3 человеческих жизни.
Короче, так не работает.