Евгений Степанов @estepanov_coder
Чистый кот
Information
- Rating
- Does not participate
- Location
- Тула, Тульская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Backend Developer, Fullstack Developer
Middle
Python
Django
PostgreSQL
Docker
Linux
Git
JavaScript
JQuery
Flask
Selenium
В целом согласен. В данном примере еще и 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 лучшая, а лишь то, какая книга была полезна на моём пути)
Спасибо за приведённый перечень, думаю, он многим поможет.