Покопавшись в коде PyYAML (версия 6.0) можно заметить что в yaml.safe_dump нельзя передать свой Dumper в отличии yaml.dump
yaml.safe_dump в обязательном порядке использует свой SafeDumper и это нельзя переопределить. Однако вам ни кто не запрещает построить свой Dumper наследуя от SafeDumper. И уже его передать в yaml.dump.
class IndentSafeDumper(yaml.SafeDumper):
def increase_indent(self, flow=False, indentless=False):
return super(IndentSafeDumper, self).increase_indent(flow, False)
В итоге тот же результат, но с использованием SafeDumper
poetry не использует своих конфигурационных файлов и не создаёт "кучу подпапочек". Работает в соответствии с PEP 621 -- Storing project metadata in pyproject.toml
Заменяет собой venv + pip
Имеет постой интерфейс понятный как раз для новичков. Тут недавно статья отнёс была с обсуждением плюсов Статья
Начинающему, да же изучавшему git, сделавшему какой-то учебный проект, даже с размещением на GutHub - всё равно сложно решиться. А тут простой пошаговый гайд. В этом и смысл.
Советы надо не здесь писать , а автору оригинального текста.
Сама статья "ниочём" в такой подаче. Если б была рассказана история успеха или не успеха, было б интересно. Можно делать какие-то выводы.
Оригинальный пост был размещён 25 апреля. С тех пор на эту тему от автора информации нет. О том что он не хочет работать на корпорации бесплатно он написал ещё в ноябре 2020 https://github.com/Marak/faker.js/issues/1046
Infrastructure as code (IaC), шутка хоть и не древняя, но и не новая, по меркам автора статьи. Википедия отправляет нас в 2006 год.
Immutable Infrastructure - это действительно свежачёк. Известна точная дата появления термина 26 июня 2013 года Chad Fowler наиисал статью и твитнул о ней (вот этот твит)
Вы путаете предмет обсуждения. При этом опираясь на умозрительные примеры названий.
Фасад тут не при чём. И с точки зрения нейминга подобное название Фасада то же плохое. Фасад прячет сложность, оставляя наружу только нужное.
Моё замечание касалось имени. Имя предполагает два действия и логический оператор. Что делает функция в данном конкретном месте нельзя понять не изучив её код.
Идея предложенной здесь https://habr.com/ru/post/558874/ методики (как и многих других) в том чтоб сделать код понятным для чтения.
getFolder - вообще ни когда не понятно что тут происходит. Получаем путь к папке? Получаем доступ к папке? Получаем содержимое папки? Имя папки?....
Вы в одном комментарии смешиваете кислое с горячим.
В начале пишете про функции, а потом "понимаете" про товарные позиции.
Товарные позиции так назывались ранее по простой причине - не было баз данных. Были листочки на которых писали. В лучшем случае разлиновывали таблички. В современном мире ваш «Болт, M12, оцинкованный» ляжет в БД с полями item size material а на ценнике будет напечатано так же как и ранее «Болт, M12, оцинкованный». Вот только ни какой связи с неймингом в программировании эти товарные позиции не имеют.
Вернусь к функциям.
Во-первых не "прям ужасно" и по-английски читается часто как обычный текст на языке. Встречаются варианты когда объект указывается в начале, а действие после него. Имеет право на жизнь оба варианта. Вопрос договорённостей внутри команды.
И это не зависит от "общих библиотек" или "конкретного домена". Функция или метод это всегда действие - поэтому глагол.
Я поправил пример в тексте перевода на текст из оригинала
4. Should Reflect expected result
/* Bad */
const isEnabled = (itemsCount > 3)
return <Button disabled={!isEnabled}/>
/* Good */
const isDisabled = (itemsCount <= 3)
return <Button disabled={isDisabled}/>
Точка зрения очень тут понятная: Имя должно отражать ожидаемый результат
В примере кнопка disabled но в первом случае контрольная переменная называется isEnabled и потом ее приходиться применять через отрицание. Лучше было сразу создать isDisabled - в этом случае название соответствует ожидаемому результату.
Зря автор не стал писать комментарий к оригинальной статье. Интересное обсуждение развалилось на два. Ну да ладно.
Код пишется для человека. В этом у нас нет расхождений. Совсем будет хорошо, если ваш код поймёт человек имеющий только общее представление о его назначении.
А вот дальше у вас написано совсем не про чистый совершенный код:
Поэтому, пока он читает слова should, display, pagination, у него из памяти вытесняются другие объекты, возможно детали алгоритма, которые он пытается понять, читая исходный код. В итоге, человек хуже поймет алгоритм, и сделает ошибку при его исправлении или использовании. Слишком описательные названия, как ни странно, ведут к прямо противоположному результату, к ухудшению понимания и большему количеству ошибок.
Если ваш код так написан, что пока его читаешь забываешь о чём прочитал, то вам точно надо его переписать. Упростить, разбить на понятные блоки/модули/функции/классы и т.п.
Любая система именования...
...ухудшает читаемость и поддерживаемость кода
Гм... В Microsoft, Google, Apple и т.д. дураки сидят и от нечего делать naming conventions используют (легко гуглится). Соглашения об наименовании для того и принимаются чтоб облегчить дальнейшую поддержку кода.
Правила наименования прекрасно вписываются в табличку. Надо просто подобрать/придумать табличку для конкретного случая. Адаптировать чьи-то рекомендации всегда проще чем придумывать с нуля.
Дальше автор зачем-то начинает пытаться разрушить предложенную методику, не предлагая при этом ни какой. Точнее предлагая писать "как хочется"
Смысл статьи в первую очередь был в том чтоб показать читателям один из подходов и объяснить его.
Тем более глупо пытаться "улучшить" модельные примеры. И упущен важный момент! Мы программируем на английском языке!!! Пытаться поправить названия через прямой, а затем обратный, переводы - это вообще не уместно.
Ещё один важный плюс от применения соглашения об именовании: люди из разных стран, языков, культур - одинаково поймут написанный код. (Например английский заметно отличается у англичан и американцев, немецкий у германских и австрийских немцев тоже. Речь не о произношении а о правилах языка)
Резюме:
Наименования переменных, функций и классов это сложно. Сложно подобрать понятные, очевидные и подчеркивающие предметную область названия.
Но совершенно точно эти названия надо уложить в стройную систему. Для улучшение читаемости кода и качества его поддержки.
Во-первых используется. Как исключение, но используется. И встречается в проектах не редко.
Во-вторых читать оригинальную статью не которую в начале текста ссылается автор. Там упоминается о том что в языках бывает своя специфика (правда вскользь)
В-третьих не стесняться думать. В оригинальной статьей предложена методика. Она не догма и, конечно, может и должна корректироваться
Покопавшись в коде PyYAML (версия 6.0) можно заметить что в
yaml.safe_dumpнельзя передать свойDumperв отличииyaml.dumpyaml.safe_dumpв обязательном порядке использует свойSafeDumperи это нельзя переопределить. Однако вам ни кто не запрещает построить свойDumperнаследуя отSafeDumper. И уже его передать вyaml.dump.В итоге тот же результат, но с использованием
SafeDumper"забавно" - единственная оценка -1 - "за личную неприязнь к автору или компании"
У кого-то ко мне личная неприязнь?! Считаю это уже популярностью )))
Это проблема хабровского редактора - сейчас поправлю. Код тут https://github.com/AABur/summarize_dataframe
poetry не использует своих конфигурационных файлов и не создаёт "кучу подпапочек". Работает в соответствии с PEP 621 -- Storing project metadata in pyproject.toml
Заменяет собой venv + pip
Имеет постой интерфейс понятный как раз для новичков. Тут недавно статья отнёс была с обсуждением плюсов Статья
Всем комментаторам.
Эта статья ориентирована в первую очередь на тех у кого нет опыта. Помогает выбрать из кучи существующих утилит рабочий и удобный вариант.
Если хотите предложить что-то другое - аргументируйте подробно. Это будет полезно всем.
К сожалению в Python в принципе зоопарк с тулзовинами по управлению зависимостями. Это просто один из не плохих современных вариантов.
Начинающему, да же изучавшему git, сделавшему какой-то учебный проект, даже с размещением на GutHub - всё равно сложно решиться. А тут простой пошаговый гайд. В этом и смысл.
Материал, конечно интересный. Особенно для новичков в Python. Но...
Во-первых, не указано что это перевод. И перевод сделанный куриной лапой на коленке! И текст не оформлен нормально.
Во-вторых, Уже давно существует грамотный перевод этого текста https://proglib.io/p/skrytye-sokrovishcha-python-2021-04-23
Советы надо не здесь писать , а автору оригинального текста.
Сама статья "ниочём" в такой подаче. Если б была рассказана история успеха или не успеха, было б интересно. Можно делать какие-то выводы.
Оригинальный пост был размещён 25 апреля. С тех пор на эту тему от автора информации нет. О том что он не хочет работать на корпорации бесплатно он написал ещё в ноябре 2020 https://github.com/Marak/faker.js/issues/1046
Его https://fakercloud.com/pricing платный.
Короче НИОЧЁМ!
Это, не совсем про программирование.
Infrastructure as code (IaC), шутка хоть и не древняя, но и не новая, по меркам автора статьи. Википедия отправляет нас в 2006 год.
Immutable Infrastructure - это действительно свежачёк. Известна точная дата появления термина 26 июня 2013 года Chad Fowler наиисал статью и твитнул о ней (вот этот твит)
Вы путаете предмет обсуждения. При этом опираясь на умозрительные примеры названий.
Фасад тут не при чём. И с точки зрения нейминга подобное название Фасада то же плохое. Фасад прячет сложность, оставляя наружу только нужное.
Моё замечание касалось имени. Имя предполагает два действия и логический оператор. Что делает функция в данном конкретном месте нельзя понять не изучив её код.
Идея предложенной здесь https://habr.com/ru/post/558874/ методики (как и многих других) в том чтоб сделать код понятным для чтения.
getFolder - вообще ни когда не понятно что тут происходит. Получаем путь к папке? Получаем доступ к папке? Получаем содержимое папки? Имя папки?....
Вопрос вкуса и договорённости в команде. Но важно чтоб в одном проекте было единообразно.
Вы в одном комментарии смешиваете кислое с горячим.
В начале пишете про функции, а потом "понимаете" про товарные позиции.
Товарные позиции так назывались ранее по простой причине - не было баз данных. Были листочки на которых писали. В лучшем случае разлиновывали таблички. В современном мире ваш «Болт, M12, оцинкованный» ляжет в БД с полями
item size materialа на ценнике будет напечатано так же как и ранее «Болт, M12, оцинкованный». Вот только ни какой связи с неймингом в программировании эти товарные позиции не имеют.Вернусь к функциям.
Во-первых не "прям ужасно" и по-английски читается часто как обычный текст на языке. Встречаются варианты когда объект указывается в начале, а действие после него. Имеет право на жизнь оба варианта. Вопрос договорённостей внутри команды.
И это не зависит от "общих библиотек" или "конкретного домена". Функция или метод это всегда действие - поэтому глагол.
Я поправил пример в тексте перевода на текст из оригинала
Точка зрения очень тут понятная: Имя должно отражать ожидаемый результат
В примере кнопка
disabledно в первом случае контрольная переменная называетсяisEnabledи потом ее приходиться применять через отрицание. Лучше было сразу создатьisDisabled- в этом случае название соответствует ожидаемому результату.Зря автор не стал писать комментарий к оригинальной статье. Интересное обсуждение развалилось на два. Ну да ладно.
Код пишется для человека. В этом у нас нет расхождений. Совсем будет хорошо, если ваш код поймёт человек имеющий только общее представление о его назначении.
А вот дальше у вас написано совсем не про чистый совершенный код:
Если ваш код так написан, что пока его читаешь забываешь о чём прочитал, то вам точно надо его переписать. Упростить, разбить на понятные блоки/модули/функции/классы и т.п.
Гм... В Microsoft, Google, Apple и т.д. дураки сидят и от нечего делать naming conventions используют (легко гуглится). Соглашения об наименовании для того и принимаются чтоб облегчить дальнейшую поддержку кода.
Правила наименования прекрасно вписываются в табличку. Надо просто подобрать/придумать табличку для конкретного случая. Адаптировать чьи-то рекомендации всегда проще чем придумывать с нуля.
Дальше автор зачем-то начинает пытаться разрушить предложенную методику, не предлагая при этом ни какой. Точнее предлагая писать "как хочется"
Смысл статьи в первую очередь был в том чтоб показать читателям один из подходов и объяснить его.
Тем более глупо пытаться "улучшить" модельные примеры. И упущен важный момент! Мы программируем на английском языке!!! Пытаться поправить названия через прямой, а затем обратный, переводы - это вообще не уместно.
Ещё один важный плюс от применения соглашения об именовании: люди из разных стран, языков, культур - одинаково поймут написанный код. (Например английский заметно отличается у англичан и американцев, немецкий у германских и австрийских немцев тоже. Речь не о произношении а о правилах языка)
Резюме:
Наименования переменных, функций и классов это сложно. Сложно подобрать понятные, очевидные и подчеркивающие предметную область названия.
Но совершенно точно эти названия надо уложить в стройную систему. Для улучшение читаемости кода и качества его поддержки.
Во-первых используется. Как исключение, но используется. И встречается в проектах не редко.
Во-вторых читать оригинальную статью не которую в начале текста ссылается автор. Там упоминается о том что в языках бывает своя специфика (правда вскользь)
В-третьих не стесняться думать. В оригинальной статьей предложена методика. Она не догма и, конечно, может и должна корректироваться
getOrCreateFolder() - это вообще не хорошо. Нарушен Принцип единственной ответственностиДействительно, "ожидаемые результат" при редактировании потерялся! Исправил. Спасибо!
Прошу написать по конкретнее про «кучу ошибок в самом посте»