Нет под рукой книги, открыл Википедию. Приспособленец там сделан через фабрику. Зачем делать через глобальный Стейт - неясно, если только ради статьи.
Прототип юзаю для всяких "дефотнных конфигураций". Создал один экземпляр класса, настроил. А дальше конструируешь не с нуля, на базе него, меняя только то что передал юзер. Может быть не каждый раз нужно использовать, но подход полезный
Пометить код устаревшим это прикольно, но это не архитектура, это просто пометка на конкретном коде, выполненная при наличии информации об этом.
Проблема устаревания кода не в том что у вещей есть срок годности, а в том что вещи меняются так сильно, что надо менять не отдельные функции, а то как устроено приложение из-за сильного изменения разноцровневой логики. А так же в том, что изменения произошли не там, где мы ожидали.
Билдер в питоне действительно часто лишний из-за наличия keyword-аргументов функции, но на самом деле это очень удобная вещь, когда речь идёт о конструировании со сложной логикой. Query builder из ORM это буквально тот же паттерн.
Синглтон же - просто антипаттерн как и всякие мутабельные статические переменные (только хуже).
Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
locale это не сторонняя библиотека, это встроенная. Если я правильно помню, в ней есть ограничения по падежам ("5 мая" получить можно, "май" - нельзя).
Имхо, падежи не меняются диамически, они не зависят от подставляемых данных. Вы просто формируете фразу сразу в нужном падеже. Но да, так мы ограничены в динамической сборке из кусков
По моим ощущения rst как раз спасение от боли нестандартизированного markdown. Markdown - это даже не формат, а куча диалектов, Mkdocs вводит свои расширения. Кроссдокументные ссылки, например, мне не понравились как там сделаны.
Да, rst своеобразный формат, но когда я пытался делать документацию для своего проекта на mkdocs, я быстро сдался и решил потратить время на изучение rst и он оказался не таким уж сложным
В связи с этим хотелось бы понять, было ли какое-то объективное сранение или вы как и я выбрали просто что показалось приятнее в использовании?
Судя по тому, что я увидел в коде это именно что контейнер, через который идет доступ к изображениям в другом формате. А вот jpeg, png которые вы обозвали просто контейнерами - полноценные форматы изображений со своими алгоритмами сжатия, например.
При работе с жсончиками мы упираемся во взаимодействие питона и раста. То есть можно сколько угодно быстро делать куски парсинга, а потом всё равно создавать питоновские объекты. Например, вот python-only библиотека которая работает не медленнее pydantiс, а то и быстрее https://adaptix.readthedocs.io/en/latest/benchmarks.html
С циклическими импортами в питоне проблем нет. Они работают. Есть проблемы с циклическими зависимостями и эту проблему надо решать в зависимости от ситуации. Как правило либо введением доп сущностей, либо убиранием одной из связей. Иногда можно попробовать и варианты с forward ref, if type checking, но очень осторожно, когда по другому точно нельзя
Вы абстрагировались не от реализаций, вы абстрагировались от здравого смысла. Если метод принимает хз что, хз как его юзать. Если наследники не совместимы с базовыми классом, почему они от него наследуются.
Нет под рукой книги, открыл Википедию. Приспособленец там сделан через фабрику. Зачем делать через глобальный Стейт - неясно, если только ради статьи.
Прототип юзаю для всяких "дефотнных конфигураций". Создал один экземпляр класса, настроил. А дальше конструируешь не с нуля, на базе него, меняя только то что передал юзер. Может быть не каждый раз нужно использовать, но подход полезный
Первая нужна чтобы при ошибке закрыть. А вторая нужна чтобы при отсутствии ошибок закрыть и обработать ошибку закрытия
Пометить код устаревшим это прикольно, но это не архитектура, это просто пометка на конкретном коде, выполненная при наличии информации об этом.
Проблема устаревания кода не в том что у вещей есть срок годности, а в том что вещи меняются так сильно, что надо менять не отдельные функции, а то как устроено приложение из-за сильного изменения разноцровневой логики. А так же в том, что изменения произошли не там, где мы ожидали.
Билдер в питоне действительно часто лишний из-за наличия keyword-аргументов функции, но на самом деле это очень удобная вещь, когда речь идёт о конструировании со сложной логикой. Query builder из ORM это буквально тот же паттерн.
Синглтон же - просто антипаттерн как и всякие мутабельные статические переменные (только хуже).
если выписать акууратно все детали - не будет
вы хотели сказать - так как нет четких правил, каждый будет понимать её как хочет?
нельзя, в большинстве случаев мы пишем код с использованием разных библиотек, а они очень разные
к черту детали, хочу бэкап своих данных в скворцах
Где можно посмотреть эти приложения?
Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
locale это не сторонняя библиотека, это встроенная. Если я правильно помню, в ней есть ограничения по падежам ("5 мая" получить можно, "май" - нельзя).
Имхо, падежи не меняются диамически, они не зависят от подставляемых данных. Вы просто формируете фразу сразу в нужном падеже. Но да, так мы ограничены в динамической сборке из кусков
Минималистично API это, конечно, хорошо, но
Какие инструменты для переводчиков вы предлагаете?
Как происходит плурализация? (1 яблоко, 2 яблока, 5 яблок / 1 apple, 2 apples, 5 apples)
Как насчет локализации чисел? (1 000,15 vs 1,000.15)
В репозитории обычно есть коммиты. Покажите как ваша система будет меняться при изменении требований, при исправлении багов.
По моим ощущения rst как раз спасение от боли нестандартизированного markdown. Markdown - это даже не формат, а куча диалектов, Mkdocs вводит свои расширения. Кроссдокументные ссылки, например, мне не понравились как там сделаны.
Да, rst своеобразный формат, но когда я пытался делать документацию для своего проекта на mkdocs, я быстро сдался и решил потратить время на изучение rst и он оказался не таким уж сложным
В связи с этим хотелось бы понять, было ли какое-то объективное сранение или вы как и я выбрали просто что показалось приятнее в использовании?
Session алхимии реализует паттерн UoW. Ваша обёртка, дающая доступ к репоизториям - это не UoW!!!
А почему не reStructuredText?
Судя по тому, что я увидел в коде это именно что контейнер, через который идет доступ к изображениям в другом формате. А вот jpeg, png которые вы обозвали просто контейнерами - полноценные форматы изображений со своими алгоритмами сжатия, например.
Формат это не программа, вы можете перерисывать код, его реализующий сколько угодно раз. Остается ли совместимость на уровне файлов изображений?
При работе с жсончиками мы упираемся во взаимодействие питона и раста. То есть можно сколько угодно быстро делать куски парсинга, а потом всё равно создавать питоновские объекты. Например, вот python-only библиотека которая работает не медленнее pydantiс, а то и быстрее https://adaptix.readthedocs.io/en/latest/benchmarks.html
Я сам не включал и никуда не логинился. В любом случае, для меня критично как он буквы показывает, поэтому удалил, попробую через пару лет ещё раз
С циклическими импортами в питоне проблем нет. Они работают. Есть проблемы с циклическими зависимостями и эту проблему надо решать в зависимости от ситуации. Как правило либо введением доп сущностей, либо убиранием одной из связей. Иногда можно попробовать и варианты с forward ref, if type checking, но очень осторожно, когда по другому точно нельзя
Не под реализацию, а под использование. Реализаций может быть несколько совместимых
Вы абстрагировались не от реализаций, вы абстрагировались от здравого смысла. Если метод принимает хз что, хз как его юзать. Если наследники не совместимы с базовыми классом, почему они от него наследуются.