Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
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, но очень осторожно, когда по другому точно нельзя
Вы абстрагировались не от реализаций, вы абстрагировались от здравого смысла. Если метод принимает хз что, хз как его юзать. Если наследники не совместимы с базовыми классом, почему они от него наследуются.
А почему в базовом классе репозитория у вас арго/кварги и возвращают методы непонятно что? Если вспомнить LSP, то любая реализация репозитория должна будет тоже поддерживать произвольное количество аргументов. Но в люди случае, сервису непонятно что туда передавать.
если выписать акууратно все детали - не будет
вы хотели сказать - так как нет четких правил, каждый будет понимать её как хочет?
нельзя, в большинстве случаев мы пишем код с использованием разных библиотек, а они очень разные
к черту детали, хочу бэкап своих данных в скворцах
Где можно посмотреть эти приложения?
Простите, я не понимаю как вы собираетесь учитывать число в плурализации, если это буквально про числа. Контекст и падежи часто заданы прям в переводе, вы же не собираете предложение из отдельных слов. Но в любом случае, спасибо, ограничение либы понятно.
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, но очень осторожно, когда по другому точно нельзя
Не под реализацию, а под использование. Реализаций может быть несколько совместимых
Вы абстрагировались не от реализаций, вы абстрагировались от здравого смысла. Если метод принимает хз что, хз как его юзать. Если наследники не совместимы с базовыми классом, почему они от него наследуются.
А почему в базовом классе репозитория у вас арго/кварги и возвращают методы непонятно что? Если вспомнить LSP, то любая реализация репозитория должна будет тоже поддерживать произвольное количество аргументов. Но в люди случае, сервису непонятно что туда передавать.
У меня в Kubuntu все ещё криво рендерит текст. А LSP просто подвисает после каждой подсказки на минуту.
Зачем использовать зрение, если мы хотим абстракции программировать. Давайте в лобные доли сразу
Во-первых, не вижу этого в лицензии
Во-вторых, это типичная дискриминация
В-третьих, это привязка к стороннему проприетарному сервису, что явно противоречит принципам свободного ПО