> А ещё есть одно неудобство, когда нужно временно закомментировать блок try, так
> чтобы его внутренности продолжали работать. Бывает нужно понять, какое там исключение
> возникает, но для этого каждый раз приходится отступы исправлять - не удобно. Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.
> Ну, если вам так нравится читать, то читайте. Я - как чукча
> из анекдота, не читатель, а писатель. По мне, чем реже приходится
> прибегать к чтению и чем проще необходимую информацию уместить в голове,
> тем проще - программа быстрее пишется и отлаживается.
PEP8 - это КРАЙНЕ РЕКОМЕНДУЕМЫЙ СТАНДАРТ. И, встретя код другого "живущего по pep8 и pep20", я его легко пойму. Более того, на более-менее простой задаче два "живущих по pep8 и pep20" решат её абсолютно одинаково. :)
Наличие стандарта - это большой плюс. А позиция "я тут самый умный, и мне наплевать, кто там что будет читать, моё дело - писать" - очень усложняет поддержку.
> От какой последней линии? Кончается сразу несколько блоков, а начала блоков не
> видно. Не понятно на глаз, какие блоки уже закончились, а какие - нет.
- Люся, я на кладбище
- Кто-то умер?
- Ты не поверишь, ТУТ ВСЕ УМЕРЛИ!
То ли у нас разные русские языки, то ли разные восприятия. Если ничего снизу не торчит, то все блоки закончились. И это нормально, это самая популярная практика, просто пишешь сверху вниз, а потом не нужно задумываться о том, что где закрывать. Если такой условный пример разбавить скобочками, то сразу возрастёт сложность - их нужно будет где-то закрывать, либо }}}}, либо четыре строчки в ряд, либо "превращать perl в python, но со скобочками", ставя их ровно на линии, и получая ровно те же самые блоки, но с ни-к-селу-ни-к-городу скобочками.
> Насчёт гибкости у меня такая проблема - я хочу чтобы интерпретатор ловил
> опечатки в именах переменных. В Perl есть прагма strict и родственная
> ей fields - от таких нелепых ошибок спасает, просто не даёт
> запустить программу с такими ошибками. В Python если программа запустилась, то
> это ещё не значит, что в программе нет опечаток. Иногда так
> поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за
> опечатки. Куча времени теряется впустую.
dict, locals, globals. Всё есть словарь, и каждый словарь можно контролировать, если очень хочется. И, опять же, какие-то странные позывы - добавил кода, но не проверил, а через полчаса оно вывалилось? А если оно вывалилось не из-за опечатки, а из-за кривого алгоритма или лексически грамотной, но технически ошибочной конструкции? Такие вещи встречаются намного чаще - как можно не проверять то, что написал?
Короче говоря, python - это для разработчиков, которые хотят сделать код, который был бы понятным другим разработчикам, чтобы развивать его вместе и придумывать новое на его основе. А perl - для программистов (не знаю, для кого как, а для меня это слово ругательное, и лично я могу за него и в дыню дать), которые написали и свалили, и ничего их не колышет, работает - и ладно, а прочие тонкости и прочие люди уже никак не волнуют. Лично я КАЖДУЮ строчку проверяю на предмет того, "а понятно будет ли это пыхеру, которого я на улице отловлю за руку, и посажу это читать?". Могу использовать и менее эффективные и более громоздкие конструкции только для того, чтобы они были понятнее, чтобы с этим можно было реально работать, менять и дополнять (даже тем людям, которые в python понимают слабо), чтобы у написанного была дальнейшая жизнь.
И в мире, где opensource стало царицей полей - это очень важно. Поддерживаемость - это основной козырь ранее написанного кода, чтобы не пришлось его переизобретать. Именно на этом основывается преимущество opensource.
