Paradigm Linter

[vitus_wagner]

вот тут nataraj в очередной раз ругает Python. Но по-моему зря ругает. К сожалению это общее правило. Ежели нечто у нас практически полезное, оно не может быть концептуально чистым. Его задача get things done, а не научить людей правильно мыслить. Нельзя вырезать узор на дереве инструментом, который не позволяет порезаться.

Поэтому, если испольовать для обучения не игрушечные инструменты, а настоящие (кстати perl это касается в примерно той же степени), то нужен какой-то отдельный прибамбас, который будет следить за тем, чтобы ученик учился мыслить правильно, концептуально чисто, а не эклектично. (на следующем этапе обучения ученика надо будет научить когда, как и почему надо уметь отсупать от концептуальной чистоты).

Вот у нас есть такие инструменты как pylint и perlcritic, которые находят разнообразные стилистические и не только погрешности. Я вообще взял себе за правило не коммитить питоновский код, не проходящий pylint и шелловский код, не проходящий shellcheck, Потому что если проанализируешь все ворнинги этих инструментов и некоторые потключаешь управляющим комментарием в конкретном месте кода, будешь по крайней мере уверен что код делает то, что ты имел в виду.

Но для целей (само)обучения нужен инструмент более высокого уровня. Который будет тыкать в нос "вот у тебя 80% кода написано в объектной парадигме, а здесь ты почему-то используешь чисто процедурное решение". То есть отслеживать применение известных парадигм и выдавать предупреждение где происходит переключение с одной на другую. Наверное, с помощью нынешних LLM такое уже можно написать.

Видимо, тут нужен подход, подобный тому, который использует perlcritic - учебник, и в сообщениях программы линтера ссылки на конкретные разделы этого учебника, в которых достаточно пространно объяснено почему так не надо делать.

Comments

[vitus_wagner]

Внутри виртуальной машины, еще и питоновский virtualenv разводить? Интересный подход. А сама виртуальная машина не в докере, часом, запущена? А то был у нас в конторе один любитель qemu-system под докером запускать.

Системный питон много для чего предназначен. Например embed-ится в постгрес именно он.

Ну то есть да, если у тебя не дистрибутив а какой-то редхатоид, там приходится вместо системного platform-python использовать что-то другое. А platform-python оставить для нужд дистрибутива, то есть для dnf, И модули десятками самому собирать. Но поскольку я это делаю не для себя, а для клиентов, то "самому собирать" - это собирать в дистрибутивные пакеты.

Раньше это иногда приходилось и для астры делать. Но теперь мы отказались от поддержки Astra 1.6, а в 1.7 уже все не настолько старье, чтобы наши питонисты не могли с этими версиями модулей работать.

А что касается кода, написанного нами для наших собственных нужд, то там скорее приходится каждый раз при dist-upgrade на новую мажорную версию дебиана с матом править код наших скриптов для совместимости с новой версией питона. То есть питон в дистрибутиве обновляется быстрее, чем у нас возникает необходимость осваивать новые фичи или даже чем мы избавимся от deprecated фич.

Самостоятельно поддерживать всю питоновскую инфраструктуру стоит если питон у тебя основной и единственный инструмент. А если он один из десятка испоьзуемых языков, то лучше спихивать возможно большую часть работы на мейнтейнеров дистрибутивов.