Спасибо большое, но я не знаю синтаксис Haskel, мы в треде по питону. Попробую разобраться, поправляйте если я ошибся.
Давайте вернемся к определениям. Что такое композиция функция F(x) и G(x)? Это функция вида F(G(x)). Есть ли у нас такое выше? Нет.
Тут нет композиции, тут есть передача функции в функцию и частичное применение для уменьшения количества аргументов. У нас етсь функция sort_by(list, cmp) и мы её преобразовали в функцию sort(list). Да, в функциональном программировании это есть изначально и есть своя терминология для этого. Но можно так же сказать, что функция sort_by зависит от cmp. Соответсвенно, когда мы её каррируем, мы внедряем эту зависимость.
Вот вы делаете маленькие функции, но некоторые из них должны вызывать другие. Вы можете либо передавать их как параметр, либо жестко указывать в коде. В первом случае у нас работает принцип инверсии зависимости (функция не знает что она вызовет, но знает абстракцию), во втором случае у нас невозможно повторное использование функции в чуть других условиях.
Допустим, вы хотите сортировать список по ключи. Либо вы делаете конкретную функцию сортировки по каждому ключу, либо передаете (инжектируете) функцию ключа как параметр.
Погодите. Вот допустим у вас есть функция foo, которая вызывает функцию bar. Вы можете сделать это напрямую или передавать bar как аргумент. Тогда вы можете сделать foo1 = partial(foo, bar) - и вот у вас внедрение зависимости в функциональном стиле.
На мой вопрос вы так и не ответили: чем DI мешает или не помогает? Его задача одна - сделать сцепление кода ниже и тем самым изолировать слои абстракции и улучшить гибкость архитектуры. Концепция универсальная и относится не только к ООП, но и к ФП (даже если называется там по другому) и даже проектированию сервисов
Подскажите плиз, а как в opiod с кастомными скоупами? Допустим я делаю небольшой планировщик (или веб фреймворк или ещё что) и хочу чтобы на каждое событие у меня создавался один новый экземпляр соединения с БД. То есть это привязано не к тредам, а имеет конкретный огранчиенный жизненный цикл, которым будет управлять фреймворк. Можно это реалзиовать?
Единственный "нормальный DI" - это передача зависимостей при создании экземпляра. Как именно вы будете создавать эти заивисимости - это не DI, это как раз фабрики о которых спросил человек. Их можно писать вручную, можно использовать IoC-контейнеры. Важно так же понимать, что при неправильном использовании IoC контейнера можно вообще лишиться DI как такового (например, используя глобальный экземпляр контейнера по аналогии с сервис локаторами)
DI ничем не лучше фабрики. Это перпендикулярные вещи. Важно не путать концепцию Dependency Injection и DI-фреймворки aka IoC-контейнеры (один из которых описан в статье), которые по факту и являются инструментами для упрощения создания фабрик
Потому что суть анонимной функции в том, чтобы у нее не было имени (создал и передал куда-то сразу). Если нужно дать функции какое-то имя - есть обычная декларация через def. Заодно оно и в трейсах будет нормально выглядеть.
Ну и pep8 так рекомендует если моего мнения недостаточно
Лямбда может быть использована много раз, например, когда вы её передаёте дальше в качестве кольэк-функкии или ещё как. Ну и никто не мешает лямбду сохранить в переменную, хотя, конечно, это считается плохим тоном.
Спасибо. Тоже поставил себе демку на s21, действительно всё стало намного лучше чем я видел год назад. Остались кое-какие косяки (кнопка назад закрывает всё приложение, иногда отступы сползают, чекбоксы не реагируют на клик по связанному лейблу), но действительно и на палец реагирует интерактивно и рипл-эффект похож на настоящий. Хорошо, что фреймворк развивается, может быть скоро можно будет с комфортом писать под android на Python.
Вы показываете реакцию на мышку. А я говорю про события перемещения пальцем. Например, вот есть тулбар. Он может быть свернутым (одна строка текста наверху) или развернутым (текст крупнее, может быть ещё картинка на фоне). Переход из одного состояния в другой происходит плавно при движении пальцем контента (прокрутки экрана). Точно так же боковое меню выдвигается пальцем плавно, можно в любом момент палец задержать или вернуть назад. Так же интерактивно происходит листание табов уже в процессе перемещения пальца, а не в конце жеста. В частности это видно тут: https://material.io/design/interaction/gestures.html#properties или на нативных приложениях под Android.
Лаги я видел именно при запуске на телефоне, на гифках, снятых с компа естественно их не увидеть.
Обычно используют venv, так как он в коробке в отличие от virtualenv.
Если вы пропущенный импорт находите только через пару месяцев, это означает что вы не тестируете новую фичу перед выкладкой. Тут ничего не поможет
Непонятно, почему нельзя сделать дистрибутив из вашего пакета, установить и не заниматься всем этим?
За сколько секунд вы находите и исправляете потерянный импорт? Как часто это происходит?
Сколько времени уходит на поддержку этой магии и объяснения новым разработчикам как она работает? Покрыта ли она тестами?
Спасибо большое, но я не знаю синтаксис Haskel, мы в треде по питону. Попробую разобраться, поправляйте если я ошибся.
Давайте вернемся к определениям. Что такое композиция функция F(x) и G(x)? Это функция вида F(G(x)). Есть ли у нас такое выше? Нет.
Тут нет композиции, тут есть передача функции в функцию и частичное применение для уменьшения количества аргументов. У нас етсь функция sort_by(list, cmp) и мы её преобразовали в функцию sort(list). Да, в функциональном программировании это есть изначально и есть своя терминология для этого. Но можно так же сказать, что функция sort_by зависит от cmp. Соответсвенно, когда мы её каррируем, мы внедряем эту зависимость.
Вот вы делаете маленькие функции, но некоторые из них должны вызывать другие. Вы можете либо передавать их как параметр, либо жестко указывать в коде. В первом случае у нас работает принцип инверсии зависимости (функция не знает что она вызовет, но знает абстракцию), во втором случае у нас невозможно повторное использование функции в чуть других условиях.
Допустим, вы хотите сортировать список по ключи. Либо вы делаете конкретную функцию сортировки по каждому ключу, либо передаете (инжектируете) функцию ключа как параметр.
Вопрос, это все ещё костыль и анахронизм?
Погодите. Вот допустим у вас есть функция foo, которая вызывает функцию bar. Вы можете сделать это напрямую или передавать bar как аргумент. Тогда вы можете сделать foo1 = partial(foo, bar) - и вот у вас внедрение зависимости в функциональном стиле.
На мой вопрос вы так и не ответили: чем DI мешает или не помогает? Его задача одна - сделать сцепление кода ниже и тем самым изолировать слои абстракции и улучшить гибкость архитектуры. Концепция универсальная и относится не только к ООП, но и к ФП (даже если называется там по другому) и даже проектированию сервисов
И все таки раскройте мысль почему внедрение зависимостей в Python не приносить пользы и атипаттерн по вашему мнению.
А разговаривая про ФП, я не понимаю вашего противопоставления каррирования и DI, по факту это тот же механизм, но примененный функциям, а не объектам.
Подскажите плиз, а как в opiod с кастомными скоупами? Допустим я делаю небольшой планировщик (или веб фреймворк или ещё что) и хочу чтобы на каждое событие у меня создавался один новый экземпляр соединения с БД. То есть это привязано не к тредам, а имеет конкретный огранчиенный жизненный цикл, которым будет управлять фреймворк. Можно это реалзиовать?
Расскажите подробнее, почему DI - это антипаттерн. Интересно сравнить с мнением Роберта Мартина и других людей
А чем вам не хватило встроенного в fastapi `Depends`?
Единственный "нормальный DI" - это передача зависимостей при создании экземпляра. Как именно вы будете создавать эти заивисимости - это не DI, это как раз фабрики о которых спросил человек. Их можно писать вручную, можно использовать IoC-контейнеры. Важно так же понимать, что при неправильном использовании IoC контейнера можно вообще лишиться DI как такового (например, используя глобальный экземпляр контейнера по аналогии с сервис локаторами)
DI ничем не лучше фабрики. Это перпендикулярные вещи. Важно не путать концепцию Dependency Injection и DI-фреймворки aka IoC-контейнеры (один из которых описан в статье), которые по факту и являются инструментами для упрощения создания фабрик
Потому что суть анонимной функции в том, чтобы у нее не было имени (создал и передал куда-то сразу). Если нужно дать функции какое-то имя - есть обычная декларация через def. Заодно оно и в трейсах будет нормально выглядеть.
Ну и pep8 так рекомендует если моего мнения недостаточно
Лямбда может быть использована много раз, например, когда вы её передаёте дальше в качестве кольэк-функкии или ещё как. Ну и никто не мешает лямбду сохранить в переменную, хотя, конечно, это считается плохим тоном.
Насколько я понял из статьи, хотя это не было выделено явно, FOR == filter+options+response. Вопросы:
К чему относятся права пользователя? Где здесь лежит авторизация?
Почему рассматривается только запрос поиска? Если пользователь создает продукт, куда лягут данные? в options?
Как быть когда представление данных отличается от того как они хранятся?
Как быть когда мы поверх одних данных и логики делаем как веб страницы, так и некоторое API, (например, для мобильных устройств)?
Общую мысль я не вполне уловил, речь идет об описании API сервера (вспомнился GraphQL) или об архитектуре самого сервиса?
Очень желательно двойной слепой тест
Кажется, это не фабричный метод, это фабрика оформленная как статический метод.
Спасибо. Тоже поставил себе демку на s21, действительно всё стало намного лучше чем я видел год назад. Остались кое-какие косяки (кнопка назад закрывает всё приложение, иногда отступы сползают, чекбоксы не реагируют на клик по связанному лейблу), но действительно и на палец реагирует интерактивно и рипл-эффект похож на настоящий. Хорошо, что фреймворк развивается, может быть скоро можно будет с комфортом писать под android на Python.
Вы показываете реакцию на мышку. А я говорю про события перемещения пальцем. Например, вот есть тулбар. Он может быть свернутым (одна строка текста наверху) или развернутым (текст крупнее, может быть ещё картинка на фоне). Переход из одного состояния в другой происходит плавно при движении пальцем контента (прокрутки экрана). Точно так же боковое меню выдвигается пальцем плавно, можно в любом момент палец задержать или вернуть назад. Так же интерактивно происходит листание табов уже в процессе перемещения пальца, а не в конце жеста. В частности это видно тут: https://material.io/design/interaction/gestures.html#properties или на нативных приложениях под Android.
Лаги я видел именно при запуске на телефоне, на гифках, снятых с компа естественно их не увидеть.