SQL Alchemy преподносит как минимум три существенных преимущества:
Query builder. Это не часть ORM, это просто способ безопасно строить динамический SQL
Data Mapper. В отличие от Active Record мы можем маппить на доменные модели. Либо использовать модели алхимии как доменные. Во втором случае сама модель (инстанс), в целом, все ещё просто отображает данные, в БД она сам не пойдет, хотя класс и выглядит грязнее.
UoW - мы можем трекать изменения моделей, добавлять в буфер новые чтобы потом разом сохранить.
Первое (query builder) это хорошая фича для реализации слоя работы с БД, в БЛ ей не место. Второе (mapper) позволяет организовывать связь данных в БД и в БЛ. А UoW - это уже часть логики работы с данными, а именно когда они будут попадать в базу данных.
Ни одна из этих крутых фич не требует вам в бизнес логике использовать термины базы данных для построения запросов. Вы все ещё можете сделать `def find(name: str| None, price: int | None)`, а превращение этого в SQL скрыть внутри репозитория, не ломая вышеназванные фичи. А подход с GenericRepo - это как раз та сущность, что ничего толком не дает, а только загрязняет логику - мы переносим часть QueryBuilder в БЛ).
Я бы не был так строг по отношению к моделям, но вот интерфейс метода list максимально неявный, что просто лишает этот репозиторий преимуществ по сравнению с использованием голого session
Я хочу возразить. В основном гуглю то, что не требует глубины мышления - названия функций, какие-то особенности фреймворков. А глубина мышления как раз есть, она позволяет по двум словам понять о чем речь, как оно может быть устроено и выбрать на том же SO правильный в данном контексте ответ, даже если плюсики говорят другое. Мелкие детали легко находятся и постоянно меняются. А общие принципы и есть та глубина мышления, их сложно нагуглить, но они при этом прослеживаются везде.
Это хорошо, что вы не видели этот паттерн. Я видел и судя по другим комментариям, люди продолжают использовать. IoC-контейнеры же есть не у всех и не у всех скоуп синглтон называется именно так (это классическое название, но все же). Так что когда говорят "синглтон", без уточнений ожидалсь бы, что речь именно о самостоятельной сущности, а не детали реализации какой-то библиотеки (пусть даже такой большой как спринг и аналоги). Второе ожидание, что люди знакомые с IoC-контейнеоами знают и паттерн и способных их отличить. Вот вы справились, а кто-то - нет, и мне кажется виноват не автор
Что же касается книги - возраст не повод её выкидывать. Книга все ещё актуальная и рекомендуется к прочтению всем кто переходит от уровень junior дальше.
Я не предлагал писать на Си в ФП стиле. Мне это как раз кажется сомнительной идеей - нужно переизобрести инстурментарий и запретить стандартный. Но почему-то человек выше сделал вид, что все нормально.
Если для вас слова "то что считалось синглтоном перестало им быть" - демагогия, но я не знаю как ещё донести мысль. Было исходное утверждение "Тип ХХХ - синглтон", в процессе обсуждения мы таки выяснили, что нужны 2 его экземпляра (или больше). То есть исходное предположение было неверно. С синглтонами всегда так: думаешь что это железобетонно одна штука, а потом выясняется что иногда и нет. И сиди бегай все get_instance() ищи.
то тут они хоть и будут иметь один тип, но функционально это будут два отдельных объекта
вот эту часть не понял. Паттерн синглтон именно про отсутвтвие нескольких экземпляров одного типа
Именно что Под капотом. Речь шла не о том, чтобы реализовать на си код, идентичный результату компиляции ФП кода, а о том чтобы писать в ФП стиле. Ваша подкапотная магия некорректна, так как не контролирует сейчас наличие указателей на tmp. Боюсь чтобы в ФП стиле писать на Си, надо ОЧЕНЬ много ещё реализовать, а потом желательно ещё обвеситься линтерами которые будут проверять что вы не используете стандартные функции си вне этих мест
все ещё вижу `result[len]=...` - модификация уже созданной выше структуры. (Я бы ещё и на free(tmp) поворчал - мы так меняем "состояние" блока памяти, а он мог где-то использоваться). Пожалуйста, напишите код так, чтобы после первоначальной инициализации с переменной больше ничего не происходило, никак её память не менялась вами в коде, иначе это не ФП код.
Суть ФП подхода в том что изменяющие операции там отстутвтуют на уровне логики кода. Компилятор конечно же их реализует сам, но в этом и суть - вы не делаете их вообще, это находится ВНЕ вашего кода
не важно, что именно меняется. в ФП изменяемые объекты/переменные/сущности/области памяти не существуют. Реализуйте пожалуйста БЕЗ изменений чего либо, чтобы показать что на Си можно писать в ФП стиле
если синглтон надо конфигурировать, значит каждый get_instance должен принимать ВСЮ конфигурацию, иначе мы не знаем с какой конфигурацией будет создан экземпляр.
Синглтон это когда один экземпляр. Почему у вас два?
Усложним, у нас приложение стало модульным монолитом (мы пока не хотим микросервисы, но готовимся). В каждом ограниченном контексте тоже есть пул соединений. Уже стало и не два, выходит.
Вызов функции не сложен. Но двухфазная инициализация используется обычно в тех случаях когда ты не можешь две фазы склеить в одну: то есть между вызовами будет что-то ещё происходить. И вот это "что-то ещё" открывает дорогу багам
SQL Alchemy преподносит как минимум три существенных преимущества:
Query builder. Это не часть ORM, это просто способ безопасно строить динамический SQL
Data Mapper. В отличие от Active Record мы можем маппить на доменные модели. Либо использовать модели алхимии как доменные. Во втором случае сама модель (инстанс), в целом, все ещё просто отображает данные, в БД она сам не пойдет, хотя класс и выглядит грязнее.
UoW - мы можем трекать изменения моделей, добавлять в буфер новые чтобы потом разом сохранить.
Первое (query builder) это хорошая фича для реализации слоя работы с БД, в БЛ ей не место. Второе (mapper) позволяет организовывать связь данных в БД и в БЛ. А UoW - это уже часть логики работы с данными, а именно когда они будут попадать в базу данных.
Ни одна из этих крутых фич не требует вам в бизнес логике использовать термины базы данных для построения запросов. Вы все ещё можете сделать `def find(name: str| None, price: int | None)`, а превращение этого в SQL скрыть внутри репозитория, не ломая вышеназванные фичи. А подход с GenericRepo - это как раз та сущность, что ничего толком не дает, а только загрязняет логику - мы переносим часть QueryBuilder в БЛ).
Я бы не был так строг по отношению к моделям, но вот интерфейс метода list максимально неявный, что просто лишает этот репозиторий преимуществ по сравнению с использованием голого session
Вот только pydantic settings делает очень неявные предполжения и может прочитать переменную окружения
UsErвместоUSERIoC-контейнер для python
https://github.com/reagento/dishka/
Я хочу возразить. В основном гуглю то, что не требует глубины мышления - названия функций, какие-то особенности фреймворков. А глубина мышления как раз есть, она позволяет по двум словам понять о чем речь, как оно может быть устроено и выбрать на том же SO правильный в данном контексте ответ, даже если плюсики говорят другое. Мелкие детали легко находятся и постоянно меняются. А общие принципы и есть та глубина мышления, их сложно нагуглить, но они при этом прослеживаются везде.
Назвать проект venv - это жестоко. Запутать всех решили?
я взял небольшой массив размером 1000000 чисел (это же 4мб памяти, да?) что-то падает, не подскажете почему?
Попробуйте код чуть посложнее - напишите функцию поиска максимума в ФП стиле
Это хорошо, что вы не видели этот паттерн. Я видел и судя по другим комментариям, люди продолжают использовать. IoC-контейнеры же есть не у всех и не у всех скоуп синглтон называется именно так (это классическое название, но все же). Так что когда говорят "синглтон", без уточнений ожидалсь бы, что речь именно о самостоятельной сущности, а не детали реализации какой-то библиотеки (пусть даже такой большой как спринг и аналоги). Второе ожидание, что люди знакомые с IoC-контейнеоами знают и паттерн и способных их отличить. Вот вы справились, а кто-то - нет, и мне кажется виноват не автор
Что же касается книги - возраст не повод её выкидывать. Книга все ещё актуальная и рекомендуется к прочтению всем кто переходит от уровень junior дальше.
Нет, это выясняется раз в год (когда уже всё обрастает мясом и использванием его). И ты сидишь и тратишь недели на попытки избавиться от него
Я не предлагал писать на Си в ФП стиле. Мне это как раз кажется сомнительной идеей - нужно переизобрести инстурментарий и запретить стандартный. Но почему-то человек выше сделал вид, что все нормально.
Если для вас слова "то что считалось синглтоном перестало им быть" - демагогия, но я не знаю как ещё донести мысль. Было исходное утверждение "Тип ХХХ - синглтон", в процессе обсуждения мы таки выяснили, что нужны 2 его экземпляра (или больше). То есть исходное предположение было неверно. С синглтонами всегда так: думаешь что это железобетонно одна штука, а потом выясняется что иногда и нет. И сиди бегай все
get_instance()ищи.вот эту часть не понял. Паттерн синглтон именно про отсутвтвие нескольких экземпляров одного типа
Именно что Под капотом. Речь шла не о том, чтобы реализовать на си код, идентичный результату компиляции ФП кода, а о том чтобы писать в ФП стиле. Ваша подкапотная магия некорректна, так как не контролирует сейчас наличие указателей на
tmp. Боюсь чтобы в ФП стиле писать на Си, надо ОЧЕНЬ много ещё реализовать, а потом желательно ещё обвеситься линтерами которые будут проверять что вы не используете стандартные функции си вне этих местТак погодите, выше утверждалось, что пул - синглтон, а теперь он как раз и не синглтон.
все ещё вижу `result[len]=...` - модификация уже созданной выше структуры. (Я бы ещё и на free(tmp) поворчал - мы так меняем "состояние" блока памяти, а он мог где-то использоваться). Пожалуйста, напишите код так, чтобы после первоначальной инициализации с переменной больше ничего не происходило, никак её память не менялась вами в коде, иначе это не ФП код.
Суть ФП подхода в том что изменяющие операции там отстутвтуют на уровне логики кода. Компилятор конечно же их реализует сам, но в этом и суть - вы не делаете их вообще, это находится ВНЕ вашего кода
не важно, что именно меняется. в ФП изменяемые объекты/переменные/сущности/области памяти не существуют. Реализуйте пожалуйста БЕЗ изменений чего либо, чтобы показать что на Си можно писать в ФП стиле
если синглтон надо конфигурировать, значит каждый get_instance должен принимать ВСЮ конфигурацию, иначе мы не знаем с какой конфигурацией будет создан экземпляр.
Синглтон это когда один экземпляр. Почему у вас два?
Усложним, у нас приложение стало модульным монолитом (мы пока не хотим микросервисы, но готовимся). В каждом ограниченном контексте тоже есть пул соединений. Уже стало и не два, выходит.
Вызов функции не сложен. Но двухфазная инициализация используется обычно в тех случаях когда ты не можешь две фазы склеить в одну: то есть между вызовами будет что-то ещё происходить. И вот это "что-то ещё" открывает дорогу багам
вижу изменение: `result[i]=do_something`. Пожалуйста, продемонстрируйте код, где не будет изменяемых переменных