Я думал, я один тут заморочен на code style, code review, единости и целостности проекта, соответствие его общемировым стандартам и практикам, лёгкостью поддержки и развития посредством расширения команды разработчиков.
Это не потеря запятой. Это не ошибка. Это базис, основа языка Python. Почитайте что-нибудь про язык, прежде чем начинать на нём писать, или возвращайтесь на Си или переходите на раби-перл-что-там-ещё — вам так проще будет.
Именно утилиты внутренней автоматизации нужно покрывать тестами в первую очередь.
Если весь проект ляжет тупо из-за того, что была ошибка в скрипте раскладки (к примеру) — попа будет болеть долго.
А это не ошибочный код — с точки зрения питона код в топике валидный — я сам так разбиваю строки, когда они слишком длинные. Поэтому ни один валидатор не поймёт, корректен ли этот код, или это ощибка кодера.
ИМХО, проблема высосана из пальца, и решение просто ужасно.
Вот честно, — ни разу вообще не сталкивался на практике с такого рода ошибками, а из-за невнимательности разработчика можно наделать гораздо более серьёзные ошибки.
Код таких неопытных программистов я всегда (!) прогояю через code-review — в таком случае выявляются 99% таких (и всех других прочих) опечаток.
$ pep8 test.py
test.py:2:7: E121 continuation line indentation is not a multiple of four
test.py:2:16: E203 whitespace before ','
test.py:3:16: E203 whitespace before ','
test.py:4:16: E203 whitespace before ','
Совсем не pythonic-way. Больше похоже на JavaScript.
Про PEP-8 автор, конечно, не в курсе, — советую ознакомиться.
И проблемой это не является — вкрутить проверку кода на соответствие PEP8 (утилиты "pep8", или даже "flake8", что ещё кошернее) в редактор при сохранении или в git (mercurial) хуком при коммите — дело трёх минут.
➜ time grep volume system.log 1>/dev/null
real 0m0.025s
user 0m0.020s
sys 0m0.006s
➜ time cat system.log | grep volume 1>/dev/null
real 0m0.055s
user 0m0.023s
sys 0m0.019s
Если человек пишет cat | grep, значит, он не знает, как работает та или иная команда. В одном случае лучше одно, в другом случае лучше другое, и это хорошо, если ты делаешь что-то осознанно. Если бездумно повторять одну и ту же команду, подсмотренную в гугле во всех случаях, — стоит ли говорить о том, что ты хорошо знаешь консоль?
Удваиваю.
EDIT: не туда написал. ответ на комментарий Semy.
Ошибку в «mrad» поправил, спасибо за замечание.
EDIT: OS X 10.8.2, Python 2.7.3
Переходить на личности и «умиляться», уподобляясь вам не буду.
P.S. Вот за такой лапшевидный php-style код: bitbucket.org/eyeofhell/sigma/ я бы гнал своего бойца в три шеи. Слава Богу, таких не держим ;)
Если весь проект ляжет тупо из-за того, что была ошибка в скрипте раскладки (к примеру) — попа будет болеть долго.
ИМХО, проблема высосана из пальца, и решение просто ужасно.
Вот честно, — ни разу вообще не сталкивался на практике с такого рода ошибками, а из-за невнимательности разработчика можно наделать гораздо более серьёзные ошибки.
Код таких неопытных программистов я всегда (!) прогояю через code-review — в таком случае выявляются 99% таких (и всех других прочих) опечаток.
Ну и тесты, тесты, тесты, тесты, тесты.
Про PEP-8 автор, конечно, не в курсе, — советую ознакомиться.
И проблемой это не является — вкрутить проверку кода на соответствие PEP8 (утилиты "pep8", или даже "flake8", что ещё кошернее) в редактор при сохранении или в git (mercurial) хуком при коммите — дело трёх минут.
Даже на не самом большом файле разница очевидна.
Плюс добавил обработку очень длинных путей — текущая рабочая директория обрезается при выводе слева.