Понял о чем вы, спасибо за хороший пример. И соглашусь с вами, но все же если брать пример из статьи, то лично я быстрее пойму такую запись: HOUR_IN_SECONDS * 3, чем: 60 * 60 * 3
И быстрее пойму куда идти чтобы поменять это число. Но это имхо
2 нижних - метод нельзя вызывать у объекта напрямую. Хотя есть обходной путь, но его обычно не используют. В Python инкапусляция работает на уровне соглашений и если у метода 2 нижних подчеркивания, то к нему обращаемся только внутри класса.
1 нижнее - можно вызывать напрямую, но лучше этого не делать. Обычно используется при наследовании, когда хочешь сделать метод приватным для всего, кроме родственных классов. Я часто использую при работе с миксинами. Опять же, работает на уровне соглашений.
Да, как таковой приватности нет, но так работает Python, ему она и не нужна. Кстати есть одна библиотека с декораторами private и public, которые являются подобием private и public в других языках, например C++. Но, к сожалению, не помню ее названия
Да, нужно находить золотую середину. Например тот же type hint нет смысла указывать для __init__, ибо все и так знают для чего этот метод и что он возвращает
Понял, спасибо. Да, выглядит интересно и понятно. Наверно, писать докстрингами или хинтами - это дело вкуса. Я вот такие докстринги никогда не писал и как-то привык к хинтам. Имхо с ними код выглядит короче, а вместо описания аргумента, можно сделать ему понятное название.
Согласен что длинное, но не согласен что слишком. 23 символа по мне не так много, можно спокойно писать, не нарушая PEP. Из авторов я больше следую советам Роберта Мартина, а он, если не ошибаюсь, писал что не столь важна длина, сколько важная ясность названия
Магические и приватные это как теплое и мягкое. Лучше "Не магические приватные методы" заменить на "Приватные методы"
Согласен, заменил, спасибо.
Может быть "правила" заменить на "рекомендации", по аналогии с PEP8
Дело в том, что для меня это именно правила, и я всегда им следую, поэтому так и назвал. Возможно, кто-то тоже захочет какие-то из них сделать своими "правилами".
На счет доктестов, я пока не смог настроить их в Django-проекте, запускающемся через Docker. Точнее не "не смог", а не нашел времени чтобы разобраться.
Пока не сталкивался с тем, чтобы гуи мешали. TestExplorer, например, весьма удобно использовать. Но, возможно, спустя время я тоже приду к мнению, о котором вы написали)
В статье я приводил именно свой опыт. И начинающему (на тот момент) мне эта книга очень помогла. Я не говорю про то, какая книга для изучения Django лучшая, а лишь то, какая книга была полезна на моём пути)
Спасибо за приведённый перечень, думаю, он многим поможет.
В целом согласен. В данном примере еще и KISS нарушается.
Какая именно IDE? VS Code например не выводит комменты как подсказку
Понял о чем вы, спасибо за хороший пример. И соглашусь с вами, но все же если брать пример из статьи, то лично я быстрее пойму такую запись:
HOUR_IN_SECONDS * 3, чем:60 * 60 * 3И быстрее пойму куда идти чтобы поменять это число. Но это имхо
А что не так с этими константами?
А как же методы?
Если такое произойдет, то скорее всего в мажорной версии, что не так страшно.
2 нижних - метод нельзя вызывать у объекта напрямую. Хотя есть обходной путь, но его обычно не используют. В Python инкапусляция работает на уровне соглашений и если у метода 2 нижних подчеркивания, то к нему обращаемся только внутри класса.
1 нижнее - можно вызывать напрямую, но лучше этого не делать. Обычно используется при наследовании, когда хочешь сделать метод приватным для всего, кроме родственных классов. Я часто использую при работе с миксинами. Опять же, работает на уровне соглашений.
Да, как таковой приватности нет, но так работает Python, ему она и не нужна. Кстати есть одна библиотека с декораторами private и public, которые являются подобием private и public в других языках, например C++. Но, к сожалению, не помню ее названия
Да, нужно находить золотую середину. Например тот же type hint нет смысла указывать для __init__, ибо все и так знают для чего этот метод и что он возвращает
Да, выглядит удобно. В Python, насколько я знаю, такого нет. Можно конечно создавать свой такой класс, но каждый раз это делать - не особо хочется
Понял, спасибо. Да, выглядит интересно и понятно. Наверно, писать докстрингами или хинтами - это дело вкуса. Я вот такие докстринги никогда не писал и как-то привык к хинтам. Имхо с ними код выглядит короче, а вместо описания аргумента, можно сделать ему понятное название.
А можете привести пример с описанием в докстрингах? Просто не уверен что правильно вас понял
Согласен что длинное, но не согласен что слишком. 23 символа по мне не так много, можно спокойно писать, не нарушая PEP. Из авторов я больше следую советам Роберта Мартина, а он, если не ошибаюсь, писал что не столь важна длина, сколько важная ясность названия
Согласен, заменил, спасибо.
Дело в том, что для меня это именно правила, и я всегда им следую, поэтому так и назвал. Возможно, кто-то тоже захочет какие-то из них сделать своими "правилами".
На счет доктестов, я пока не смог настроить их в Django-проекте, запускающемся через Docker. Точнее не "не смог", а не нашел времени чтобы разобраться.
А если вместо детального ТЗ созвониться с человеком на час-два и всё ему разъяснить, так не сработает?
Кажется, у автора «накипело»)
Спасибо, попробую
Понял. Тема интересная. Можете посоветовать где и как лучше всего CI/CD изучать?
Пока не сталкивался с тем, чтобы гуи мешали. TestExplorer, например, весьма удобно использовать. Но, возможно, спустя время я тоже приду к мнению, о котором вы написали)
Вы правы, но в статье рассматривается самый простой способ автоматизации
На счет ord("А") и ord("я") согласен, так лучше будет, спасибо.
На слова разбивал, чтобы при выводе ошибки можно было понять в каком она слове
Про регулярки не думал, попробую сделать, спасибо)
В статье я приводил именно свой опыт. И начинающему (на тот момент) мне эта книга очень помогла. Я не говорю про то, какая книга для изучения Django лучшая, а лишь то, какая книга была полезна на моём пути)
Спасибо за приведённый перечень, думаю, он многим поможет.