У вас приоритет на то чтобы код было легко писать или читать?
> Инкапсуляция это зло
Пока не захочется что-то поменять в большой кодовой базе.
> Со сложными типами невозможно работать без доки
А со сложными типами которые спрятанны внутри примитивов можно без доки?
А еще можно делать простые типы. В примере с деньгами методов намного меньше, чем у Decimal.
Имена и сигнатуры методов это тоже доки. Автодополнение и переход к исходному коду не занимают много времени.
> Порядок должен быть в голове
Я работал в больших проектах. Чтобы понять какая логика скрыта за базовыми типами приходится тратить время. У класса обёртки перед этим есть огромное приимущество, можно догадаться по API. И это логичное место для документации.
> В общем валидация на беке отличалась от валидации на фронте, они обе инкапсулированы
Тут не в инкапсуляции проблема.
> Если у вас очень много кода, то пора его рефакторить, и запихивать в классы или что там в вашем языке.
Тут такой момент. От рефакторинга вы не выиграете в безопастности, всё давно уже оттестированно в том чиле пользователями. И рефакторинг будет в разы дороже, чем елси бы делать внятную систему типов под доменную модель. Это надо делать сразу это не дорого. На тестировании быстро отобьётся.
Есть еше бонус по тестированию.
email.Domain() От этого кода можно ожидать что емейл будет провалидирован и метод уже оттестирован. Тестируется юниттестами.
"user@server.domain".split("@")[0] Кстати домен будет user. Если будут две собаки, то будет неверное значение без ошибки.
Этот код с большой вероятностью будет в обработчике запроса и протестировать это можно будет только через интеграционные тесты.
The left-to-right evaluation order of the iterables is guaranteed. This makes possible an idiom for clustering a data series into n-length groups using zip(*[iter(s)]*n, strict=True). This repeats the same iterator n times so that each output tuple has the result of n calls to the iterator. This has the effect of dividing the input into n-length chunks. https://docs.python.org/3.11/library/functions.html#zip
В документации эти типы называются `non-public part of the API` (одиночное подчёркивания, применяется для функций, классов, аттрибутов классов, переменных) и `class-private members` (двойное подчёркивание, только аттрибуты класса).
Базовая гигиена важна для разработки, но про неё часто забывают. Такие статьи полезны как напоминание, что значительно улучшить код можно практически бесплатно.
Не магические приватные методы располагаются ниже магических и публичных
Магические и приватные это как теплое и мягкое. Лучше "Не магические приватные методы" заменить на "Приватные методы"
Может быть "правила" заменить на "рекомендации", по аналогии с PEP8: делайте так, если у вас нет веской причины делать по другому.
Аннотации это хорошо, и в основном просто. В редких случаях приходиться постараться, чтобы они работали и проходили линтеры.
Докстетсты это очень круто. Но в проекте где зависимости генерировались в рантайме, я не смог заставить их работать.
Попробуйте сделать обучение на работе, где расскажите как в случае ворнинга правильно менять код. Когда есть инструкция что-делать, людям будет проще делать нормально.
Главное чтобы в noqa код ошибки добавляли, если их пустыми ставить, то всё плохо будет.
В настройках flake8 есть per-file-ignore, я например для тестов убираю часть проверок.
Предположим что вы работаете с каким либо классом, в котором к примеру ~3000 строчек. Количество "принтов" увеличивается, и понять с первого раза какой "принт" к какой переменной относится становится не просто.
Это плохой код, тут не принты нужны а рефакторинг.
Немного кокретики на примере вашей библиотеки. У кода неприлично высокая цикломатическая сложность. Это проблема. Перепишите на сложность не более 10 и тогда проблема с тем, что непонятно откуда идёт печать изчезнет.
кто разрабатывает веб приложения (и не только) на удаленном сервере
Эту жутко неудобно, но иногда приходится. Я решаю эту проблему юнит тестами. При этом подходе практически ничего не надо удалённо дебажить.
Нажать рефакторинг и сделать руками выглядит быстрей.
Python Smart Execute
Чтобы выполнить файл и продолжить в консоли есть python -i, в пайчарме в настройках запуска есть галочка для этого. Запускается весь файл, а не его часть, но у меня небольшие функции и запускать кусок из них нет смысла.
Rainbow Brackets
Планин, чтобы было удобнее писать плохой код.
Extra Icons
Хотим облегчить процесс кодинга? Но как?
Из хоткеев:
ALT+ENTER quick fix.
double tap on SHIFT (search everywhere), это найти класс, функцию, файл, PyCharm action в одном меню. 4 хоткея в одном.
CTRL + RMB -> got to declaration/show usages (зависит от контекста где кликать).
В меню Help > MyProductivity есть статистика, но мне она кажется странной.
Я использую классы для dependency injection, так как без этого сложно писать юнит-тесты. Если выкинуть тесты, то эти классы можно убрать.
O в SOLID, пропагандирует содавать новый класс вместо изменения существующего. В результате код который создан в процессе эволюции продукта содержит больше классов, чем если бы его написали сразу.
В данном примере тайпхинтинг позволяет только работать с методами BaseClass.
А что там внутри для тайпхинтинга не важно. По большому счёту BaseClass это просто коллекция типа dict. Тип не знает что у него внутри, но знает как к этим внутренностям дять доступ снаружи.
В вашем же примере, с кодом работает машина и ей по большому счёту всё равно там датакласс или нет. Передайте этот тупл в конструктор вашего BaseSensors и внтури творите с ним, всё что хотите.
А что у вас с основанием для нахождения и жильём в Португалии?
В некоторых странах временный вид на жительство требует регистарции, то есть нужно снимать/иметь жильё.
То есть для меня уехать на 3 месяца, это платить аренду и там и тут или что-то придумывать и переезжать после отпуска. Уже не так дешёво получается.
У вас приоритет на то чтобы код было легко писать или читать?
> Инкапсуляция это зло
Пока не захочется что-то поменять в большой кодовой базе.
> Со сложными типами невозможно работать без доки
А со сложными типами которые спрятанны внутри примитивов можно без доки?
А еще можно делать простые типы. В примере с деньгами методов намного меньше, чем у Decimal.
Имена и сигнатуры методов это тоже доки. Автодополнение и переход к исходному коду не занимают много времени.
> Порядок должен быть в голове
Я работал в больших проектах. Чтобы понять какая логика скрыта за базовыми типами приходится тратить время. У класса обёртки перед этим есть огромное приимущество, можно догадаться по API. И это логичное место для документации.
> В общем валидация на беке отличалась от валидации на фронте, они обе инкапсулированы
Тут не в инкапсуляции проблема.
> Если у вас очень много кода, то пора его рефакторить, и запихивать в классы или что там в вашем языке.
Тут такой момент. От рефакторинга вы не выиграете в безопастности, всё давно уже оттестированно в том чиле пользователями. И рефакторинг будет в разы дороже, чем елси бы делать внятную систему типов под доменную модель. Это надо делать сразу это не дорого. На тестировании быстро отобьётся.
Есть еше бонус по тестированию.
email.Domain()От этого кода можно ожидать что емейл будет провалидирован и метод уже оттестирован. Тестируется юниттестами."user@server.domain".split("@")[0]Кстати домен будет user. Если будут две собаки, то будет неверное значение без ошибки.
Этот код с большой вероятностью будет в обработчике запроса и протестировать это можно будет только через интеграционные тесты.
Методы тоже атрибуты.
https://docs.python.org/3/tutorial/classes.html#class-objects
В документации эти типы называются `non-public part of the API` (одиночное подчёркивания, применяется для функций, классов, аттрибутов классов, переменных) и `class-private members` (двойное подчёркивание, только аттрибуты класса).
https://docs.python.org/3/tutorial/classes.html#private-variables
Оба случая поддерживаются на уровне языка.
"non-public part of the API" не импортируются при импортах звёздочкой.
А приватные методы класса не оверрайдятся при наследовании.
Базовая гигиена важна для разработки, но про неё часто забывают. Такие статьи полезны как напоминание, что значительно улучшить код можно практически бесплатно.
Магические и приватные это как теплое и мягкое. Лучше "Не магические приватные методы" заменить на "Приватные методы"
Может быть "правила" заменить на "рекомендации", по аналогии с PEP8: делайте так, если у вас нет веской причины делать по другому.
Аннотации это хорошо, и в основном просто. В редких случаях приходиться постараться, чтобы они работали и проходили линтеры.
Докстетсты это очень круто. Но в проекте где зависимости генерировались в рантайме, я не смог заставить их работать.
Добавлять новые публичные методы для тестов считается дурным тоном.
Юниттесты лежат в том-же пакете и для них можно добавить непубличные методы.
Для интеграционных проверяйте через доступное API.
Поддерживаю. Автору рекомендую изучить документацию к тестовому фрймворку, во всех нормальных фрейморках есть механизм, как это сделать красиво.
Посмотрите на модуль https://docs.python.org/3/library/abc.html
Давно, на ХP, может это был второй питон.
Попробуйте сделать обучение на работе, где расскажите как в случае ворнинга правильно менять код. Когда есть инструкция что-делать, людям будет проще делать нормально.
Главное чтобы в noqa код ошибки добавляли, если их пустыми ставить, то всё плохо будет.
В настройках flake8 есть per-file-ignore, я например для тестов убираю часть проверок.
Сейчас поправили, а раньше на виндоусе файл при падении программы оставался заблокированным и приходилось что-то делать, чтобы открыть его снова.
Можно упереться в лимит открытых файлов.
Кажется вы лечите симптомы.
Это плохой код, тут не принты нужны а рефакторинг.
Немного кокретики на примере вашей библиотеки. У кода неприлично высокая цикломатическая сложность. Это проблема. Перепишите на сложность не более 10 и тогда проблема с тем, что непонятно откуда идёт печать изчезнет.
Эту жутко неудобно, но иногда приходится. Я решаю эту проблему юнит тестами. При этом подходе практически ничего не надо удалённо дебажить.
У меня мощная машина, в общем я с вами согласен.
Нажать рефакторинг и сделать руками выглядит быстрей.
Чтобы выполнить файл и продолжить в консоли есть python -i, в пайчарме в настройках запуска есть галочка для этого. Запускается весь файл, а не его часть, но у меня небольшие функции и запускать кусок из них нет смысла.
Планин, чтобы было удобнее писать плохой код.
Хотим облегчить процесс кодинга? Но как?
Из хоткеев:
ALT+ENTER quick fix.
double tap on SHIFT (search everywhere), это найти класс, функцию, файл, PyCharm action в одном меню. 4 хоткея в одном.
CTRL + RMB -> got to declaration/show usages (зависит от контекста где кликать).
В меню Help > MyProductivity есть статистика, но мне она кажется странной.
Слишком абстрактно, где граница?
Я использую классы для dependency injection, так как без этого сложно писать юнит-тесты. Если выкинуть тесты, то эти классы можно убрать.
O в SOLID, пропагандирует содавать новый класс вместо изменения существующего. В результате код который создан в процессе эволюции продукта содержит больше классов, чем если бы его написали сразу.
В данном примере тайпхинтинг позволяет только работать с методами BaseClass.
А что там внутри для тайпхинтинга не важно. По большому счёту BaseClass это просто коллекция типа dict. Тип не знает что у него внутри, но знает как к этим внутренностям дять доступ снаружи.
Да, для человека это важно.
В вашем же примере, с кодом работает машина и ей по большому счёту всё равно там датакласс или нет. Передайте этот тупл в конструктор вашего BaseSensors и внтури творите с ним, всё что хотите.
Ну это можно и без датаклассов делать. Просто не распаковывать tuple в переменные.
А где собственно сахар? Вполне себе базовые конструкции языка.
Линтеры в общем подталкивают к такому подходу, там сильно с вложенными ифами не забалуешь.
Спасибо, посмотрю. Вот это точно стоит попробоват: baseline: integrate into a huge project