Paradigm Linter

[vitus_wagner]

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

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

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

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

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

Comments

[phd_ru]

Хи-хи, pylint. Мы на работе гоняем на проектах isort + pycodestyle + flake8 + mypy + pylint. Первые 3 быстрые, но тоже много чего находят. Последние 2 медленные, зато очень тщательные.

В личных проектах я одним flake8 обхожусь, и то не всё исправляю.

[vitus_wagner]

Там написано

It is very important to install Flake8 on the correct version of Python for your needs. If you want Flake8 to properly parse new language features in Python 3.5 (for example), you need it to be installed on 3.5 for Flake8 to understand those features. In many ways, Flake8 is tied to the version of Python on which it runs.

Увы, такой подход не для меня. Мне лично всегда требуется чтобы питоновский код работал во многих версиях питона. Примерно от 3.2.3 до 3.12

[phd_ru]

Это у тебя такой уровень неумения пользоваться питоновскими скриптами? python2.7 -m flake8, python3.7 -m flake8, python3.12 -m flake8. У меня все библиотеки поддерживают Python 2.7 и 3.4+.

[vitus_wagner]

Это я просто не держу на рабочей системе зоопарк питонов. Потому что там же и gcc зоопарк, и glibc зоопарк и openssl. Поэтому все это в соответствующих контейнерах.

[phd_ru]

Когда ты в контейнере делаешь pip install flake8, какая тебе разница, какой там Питон?

[vitus_wagner]

Я (почти) никогда не делаю pip install. Особенно в контейнерах. В рабочей системе это еще можно себе позволить, хотя вот в Debian и Ubuntu питон теперь externally managed, и pip просто не работает.

Но уж в целевых системах все что туда ставится должно ставиться из пакетов. Причем не из каких попало репозиториев, а либо из базовых репозиториев дистрибутива, либо из наших.

Но проблема то в том, что скрипт на питоне пишется один раз (и на хост системе) а вот дебажить его надо на 30 разных дистрибутивах.

[phd_ru]

Я всегда делаю только pip install. Но, разумеется, не в системный Питон, а в виртуальные среды. В т.ч. и на виртуальных машинах, и в контейнерах. Системный Питон предназначен только для нужд дистрибутива. Два пакета я позволяю себе установить в системный Питон — pip install --break-system-packages virtualenv virtualenvwrapper.

[vitus_wagner]

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

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

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

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

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

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

[vitus_wagner]

А вообще к flake8 прилагается vim-плагин khuno.И я, пожалуй, его себе поставлю, чтобы чекал в процессе редактирования.

[phd_ru]

Я пользуюсь https://github.com/nvie/vim-flake8

[vitus_wagner]

А я не польуюсь софтом с не из дистрибтива, если к тому нет крайне веских оснований. Преимущестов khuno в том, что он работает не (только) по нажатию кнопки. Фактически в режиме syntax highlighter-а.

[phd_ru]

Дистрибутив Дебиана не содержит очень много нужного или полезного. И содержит много старья, которые приходится обновлять вне дистрибутива. А на работе у меня вообще на виртуалках древний CentOS, туда я всё тащу сам.

[vitus_wagner]

Если что-то не показалось нужным ни одному из тысячи дебиановских мейнтейнеров, есть подозрение что оно не нужно и мне. И старья я как-то не особо наблюдаю. Ну это может я такой консерватор, для меня всё, что написано в этом тысячелетии - не старьё.

Ну что там старьё? clang 16.0.6 или gcc 12.2.0? Или может openssl 3.0.13, libxml2 2.9.14? Там даже постгрес вполне актуальный - 15.7, выпущенный в мае этого года.

[phd_ru]

Я ставлю зоопарк Питонов. Некоторые из них не компилируются: а некоторые компилируются, но падают в кору. Приходится ставить из conda-forge.

Некоторые важные питоновские библиотеки и программы рекомендуется обновлять: pip, setuptools, wheel. Иных библиотек вообще нет в дистрибутиве, а я ими пользуюсь. auditwheel, например. wxPython.

[phd_ru]

Я не люблю подсветку синтаксиса. Получается попугайский пёстрый разноцветный экран, в глазах рябит,

Исходный текст программы — это текст, а текст должен быть чёрными буками на белом фоне.

[vitus_wagner]

У меня вот даже в текстах на русском языке включена подсветка синтаксиса (markdown + spell check + language tool). И фон у lxterm-а черный.

[gena_t]

А пробовали у искусственного интеллекта спрашивать?

[vitus_wagner]

У меня такой видеокарты мощной нет, чтобы запускать обучалки ИИ на своем железе. ИИ,запущенному на чужом железе я не доверяю.

[gena_t]

Сейчас посмотрел на почте это ваше сообщение, а там мой комментарий передан как "А пробовали себя в области искусственного интеллекта?". То есть работает уже как человеческий мозг, запоминает очень приблизительно. Везде, я смотрю, этот интеллект суют.

[burbilog]

GPT Critic в GPT-4o весьма неплох в анализе кода, причем не только на уровне синтаксиса. Если вы отлаживаете что-то из опенсорсного софта, то какая разница, какой уровень доверия к чужому сервису, все равно будет выложено в открытый доступ?

[vitus_wagner]

Как какая разница? Мне же надо будет все его ворнинги анализировать и тратить на это свое время. Нафига мне нужен инструмент, который врет?