Comments 16
Теперь фиксим ошибки, отмеченные флейком, и пытаемся закоммитить валидный код:Есть (была?) одна проблема: валидатор проверяет состояние рабочего дерева, а не индекса. Проще говоря, существует возможность нечаянно запихнуть в репозиторий каку:
1) Пишите невалидный код
2) Добавляете файл в индекс
3) Пытаетесь сделать коммит
4) Валидатор ругается
5) Доводите файл до валидного состояния, но НЕ добавляете его повторно в индекс
6) Теперь у вас есть возможность закоммитить невалидный код из п. 2
git commit -n проще: ничего даже править не надо, сразу есть возможность. Чтобы такого не было, в любом случае надо линтер на ci сервере запускать. Ведь кто-то мог и не настроить хуки вовсе.
Только что зарепродьюсил эту ошибку с самой новой на данный момент версией (3.2.1). Вроде, в списке issues ничего подобного не проскакивало, так что, возможно они сами не знают об этой ошибке. Я зарепорчу им баг в ближайшем времени, спасибо за информацию!
Спасибо.
Субъективно, насколько Pyflakes8 лучше / удобнее, чем встроенный в Pycharm linter?
Мне кажется, что в PyCharm PyFlakes не нужен. Встроенные средства лучше. Правда в последний раз смотрел на Pyflakes очень давно. Но даже не знаю, что надо сделать, чтобы превзойти последние версии PyCharm.
Для меня тут всё очень просто: PyCharm linter очень удобный при написании кода, потому что сразу подсвечивает стилистические ошибки, но относительно Flake у него есть два недостатка:
1) Он не позволяет предотвращать коммиты ошибок (т.е. пока что интеграции встроенного линтера с системами контроля версий нет, насколько я знаю)
2) Он находится только в IDE на твоей локальной машине. Ты можешь писать великолепный код, настроив пайчармовский линтер, но недобросовестный или невнимательный коллега всё равно сможет наделать стилистических ошибок в проекте, потому что, например, не настроит все необходимые правила для пайчармовского линтера. Flake же можно вызывать во время билдов на CI, внутри Make файлов и скриптов, чтобы проверить, что с кодом всё в порядке вне контекста одной конкретной среды разработки.
На мой взгляд, одно другому не мешает, так что для максимального эфекта лучше использовать оба этих инструмента вместе.
1) Он не позволяет предотвращать коммиты ошибок (т.е. пока что интеграции встроенного линтера с системами контроля версий нет, насколько я знаю)
2) Он находится только в IDE на твоей локальной машине. Ты можешь писать великолепный код, настроив пайчармовский линтер, но недобросовестный или невнимательный коллега всё равно сможет наделать стилистических ошибок в проекте, потому что, например, не настроит все необходимые правила для пайчармовского линтера. Flake же можно вызывать во время билдов на CI, внутри Make файлов и скриптов, чтобы проверить, что с кодом всё в порядке вне контекста одной конкретной среды разработки.
На мой взгляд, одно другому не мешает, так что для максимального эфекта лучше использовать оба этих инструмента вместе.
Python хорошо проверяется на ошибки встроенным в PyCharm linter'om. Flake8 видится, как еще один проект проверки кода, по типу проектов JS linter. В большинстве случаев не хватает автокорректировки кода, как делает PostCSS с плагинами.
PyCharm'овская подсветка синтаксиса, конечно, очень хороша, но если над проектом работает больше одного человека, то её будет недостаточно. Flake8 позволяет подготовить конкретный список стилистических правил, которые должны выполняться в коде всего проекта и, в отличии от PyCharm'овского линтера, он заставляет разработчиков выполнять эти правила с помощью способов, описанных в статье: пре-коммит хуки, прогон билдов в CI и т.д.
Такая добровольно-принудительная система может быть не всем по нраву, но некоторые заказчики, например, могут быть просто очень требовательны к оформлению кода и тогда флейк поможет избежать возни с ревью и кучей обновлений с фиксами неправильного стиля.
А по поводу автокорректировки кода, в комментариях ниже рассказали про yapf, который этим как раз и занимается. На хабре по нему пока материала нет совсем, но документация у этой тулзы очень обширная, думаю, вам будет интересно ознакомиться.
Такая добровольно-принудительная система может быть не всем по нраву, но некоторые заказчики, например, могут быть просто очень требовательны к оформлению кода и тогда флейк поможет избежать возни с ревью и кучей обновлений с фиксами неправильного стиля.
А по поводу автокорректировки кода, в комментариях ниже рассказали про yapf, который этим как раз и занимается. На хабре по нему пока материала нет совсем, но документация у этой тулзы очень обширная, думаю, вам будет интересно ознакомиться.
Экспериментировал с тулзами.
В итоге пришел к такому решению:
— flake8 добавлен и для локальных тестов в `tox` — это помогает сразу видеть если написал какую-то ерунду в процессе работы еще до подготовки коммита
— в прекоммит-хук добавлены вызовы `flake` — спасает от отправки пропущенных помарок, если недочинил их на стадии подготовки
— туда же добавлен вызов yapf — очень полезная тулза, которая не просто проверяет, а чинит форматирование кода. Причем если она изменила форматирование, то она блокирует коммит. Можно открыть код и перечитать правки. С помощью `git diff --staged` сразу видно, что именно было отформатировано и добавить предлженное в индекс, чтобы заново закоммитить.
— в планах сюда же начать пользовать pylint — он сейчас прикручен, но из-за специфических срабатываний на «необьявленных» методах класса (т.е. почти все Django методы) пришлось временно отключить.
— так же добавлена на стадии CI до прогона тестов через `travis` — если все же закоммитил лажу
В итоге пришел к такому решению:
— flake8 добавлен и для локальных тестов в `tox` — это помогает сразу видеть если написал какую-то ерунду в процессе работы еще до подготовки коммита
— в прекоммит-хук добавлены вызовы `flake` — спасает от отправки пропущенных помарок, если недочинил их на стадии подготовки
— туда же добавлен вызов yapf — очень полезная тулза, которая не просто проверяет, а чинит форматирование кода. Причем если она изменила форматирование, то она блокирует коммит. Можно открыть код и перечитать правки. С помощью `git diff --staged` сразу видно, что именно было отформатировано и добавить предлженное в индекс, чтобы заново закоммитить.
— в планах сюда же начать пользовать pylint — он сейчас прикручен, но из-за специфических срабатываний на «необьявленных» методах класса (т.е. почти все Django методы) пришлось временно отключить.
— так же добавлена на стадии CI до прогона тестов через `travis` — если все же закоммитил лажу
Я бы еще предложил добавлять проверку с помощью mypy — на необязательную проверку типов. Даже если в новом коде нету аннотаций, она может проверять аргументы вызовов стандартной библиотеки, и улучшать качество кода.
Включил хуки, что-то он у меня ругается на logger.conf
«О сколько нам открытий чудных готовит просвещенья дух!» (с)
Автору — респектище!
Убил (точнее уже не «убил» и «выделил», получается) сегодня целый день на причесывание своего Django-проекта.
Узнал о себе много [не]интересного.
Автору — респектище!
Убил (точнее уже не «убил» и «выделил», получается) сегодня целый день на причесывание своего Django-проекта.
Узнал о себе много [не]интересного.
Привет, а подскажите — что я делаю не так?
Запустил flake, получил список ошибок, почистил код. Но осталось сообщение, которое меня в ступор вводит
Есть у меня вот такой импорт — да да, я знаю что это плохо, и поэтому тут вопросов не было, сделал 2 импорта, но:
Получаю сообщение флака:
Мне это показалось странным — поскольку без этих импортов код не работал. Ну да ладно, разделяю импорт на 2, пробую ещё раз:
Получаю ожидаемое — тоже самое:
Ладно, проворачиваю эксперимент — комментирую обе строки, ошибка флака ушла. Запускаю скрипт:
Бабах, скрипт перестал работать. Поскольку питон кручу от силы недели 2, не понимаю — что упущено или что не так делаю, и кому верить — работающему скрипту или ошибкам флака.
Версия python (работаю под pyenv):
Запустил flake, получил список ошибок, почистил код. Но осталось сообщение, которое меня в ступор вводит
Есть у меня вот такой импорт — да да, я знаю что это плохо, и поэтому тут вопросов не было, сделал 2 импорта, но:
from urllib.request import Request, urlopen
Получаю сообщение флака:
watchdog.py:6:1: F401 'urllib.request.Request' imported but unused
watchdog.py:6:1: F401 'urllib.request.urlopen' imported but unused
Мне это показалось странным — поскольку без этих импортов код не работал. Ну да ладно, разделяю импорт на 2, пробую ещё раз:
from urllib.request import Request
from urllib.request import urlopen
Получаю ожидаемое — тоже самое:
watchdog.py:7:1: F401 'urllib.request.Request' imported but unused
watchdog.py:8:1: F401 'urllib.request.urlopen' imported but unused
Ладно, проворачиваю эксперимент — комментирую обе строки, ошибка флака ушла. Запускаю скрипт:
Traceback (most recent call last):
File "./watchdog.py", line 66, in <module>
main()
File "./watchdog.py", line 55, in main
new_url = bing_req(URL+"?"+enc_data, header, ip, cites)
File "./watchdog.py", line 28, in bing_req
req = urllib.request.Request(url=item, headers=header)
AttributeError: module 'urllib' has no attribute 'request'
Бабах, скрипт перестал работать. Поскольку питон кручу от силы недели 2, не понимаю — что упущено или что не так делаю, и кому верить — работающему скрипту или ошибкам флака.
Версия python (работаю под pyenv):
Python 3.6.0
А для чего pyflakes8 нужен в PyCharm, который и сам умеет проверять код на PEP8?
Sign up to leave a comment.
Стильный код на Python, или учимся использовать Flake8