> Речь идёт не о PEP, речь идёт о восприятии человеком. Пробелы считать
> не нужно - достаточно видеть блоки.

Вот я о том и говорю - не видно конца блоков, когда несколько блоков заканчивается сразу. Приходится ориентироваться на отступ того, что идёт дальше, что не столь удобно.

А ещё есть одно неудобство, когда нужно временно закомментировать блок try, так чтобы его внутренности продолжали работать. Бывает нужно понять, какое там исключение возникает, но для этого каждый раз приходится отступы исправлять - не удобно. В Perl закомментировать eval и фигурные скобки, не меняя отступов, проще.

> Разумеется, PEP-8 это благо, и
> только следование ему (хотя бы по большинству пунктов), делает человека человеком
> разумным. :)
> "Если что-то не работает или не понятно - см. PEP-8". Это как
> Нагорную проповедь перечитывать - чем больше перечитываешь, тем большее открывается -
> потому что ситуации всегда разные...

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

Синтаксис Perl очень разнообразен, поэтому легко запоминается и (не удивляйтесь, но это бывает) читается. Мне конструкция вида $a->{$b}->[$c] говорит о большем, чем a[ b][c]. Мне проще запомнить операторы m// и s/// и пользоваться переменными $1, $2 и т.п., нежели лезть в документацию по модулю re и выискивать там описания методов, которые позволяют делать ровно то же самое, для чего в Perl мне не приходится заглядывать в документацию.

Мне проще найти что-то годное на CPAN, чем в pypi, потому что на CPAN можно сразу читать документацию на модуль и она, как правило, будет написана для людей, а не для машин. В Perl есть общепризнанные годные модули для большинства нужд, которые, к тому же, давно устаканились: DBI (DBD::mysql, DBD::Pg, DBD::Sybase), Net::SNMP, Net::Ping, Net::DNS, Net::LDAP, HTML::Template (дубово, но я предпочитаю логику не размазывать по шаблонам), JSON и JSON::XS, XML::Simple, LWP, чего не скажешь о Python, где ни для пинга ни для SNMP ничего толкового не найдёшь, а все варианты подключения к MS SQL требуют огромных усилий для того, чтобы просто заставить их работать.

> не pep, а pep-8, большинству пунктов которого я следую и использую 4
> пробела.

Не лампочка, а матовая лампочка.

>> выделить в отдельную подпрограмму. Но в случае со скобочками и при
>> использовании хорошего стиля, когда закрывающая скобочка стоит на одной линии с
>> открывающей скобочкой (или if), сориентироваться гораздо проще, потому что воображаемую
>> линию можно построить не только сверху, но и снизу - от
>> закрывающей скобки.
> Так и строй линию от последней линии до первой.

От какой последней линии? Кончается сразу несколько блоков, а начала блоков не видно. Не понятно на глаз, какие блоки уже закончились, а какие - нет.

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

Насчёт гибкости у меня такая проблема - я хочу чтобы интерпретатор ловил опечатки в именах переменных. В Perl есть прагма strict и родственная ей fields - от таких нелепых ошибок спасает, просто не даёт запустить программу с такими ошибками. В Python если программа запустилась, то это ещё не значит, что в программе нет опечаток. Иногда так поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за опечатки. Куча времени теряется впустую.