>>Книжка с количеством абзацев в главе более 10-и будет нечитаемой...

>Книжка, в которой значение слов(имён/местоимений) определено в предыдущем параграфе или на прошлой или на позапрошлой страницах или в начале книги в зависимости от справедливости выражений, стоящих после слов "если" в любом месте прошлого параграфа, или одного из параграфов на прошлой или позапрошлой странице _будет_ нечитаемой.

1) О чём и речь! Перечитай ещё раз внимательнее:)

2) О знаках препинания в книжке (вместо "символов пробела") ты "скромно умолчал" - выбросил из цитирования, как "неудобное":)

>if (1) { m/some{{{s/ ; print "more {{s"; # even more {{{s

>и посмотреть, что подсвечивает его любимый редактор при вводе последующих '}' ?

Твой пример - отлично показывает ЛОГИЧЕСКИЕ парные скобки в редакторе. Сюрприз?:)

>Или Led смог запрограммировать свой редактор так, что это работает правильно, не встроив в него полноценный синтаксический анализатор?

Ничего не программировал - сразу показывает. Хотя это не так и важно - я всё равно ОФОРМЛЯЮ отступами так, что и без подсветки всё видно - именно ОФОРМЛЯЮ, а не набиваю нужное количество пробелов из-за требований "синтаксиса". И, прикинь, какой ламер Д.Кнут - в его TeX'е любое количество пробелов считается за один, любое колиство пустых строк считается за одну - не довелось бедняге донкихотов почитать и поумнеть!:)

>>То есть, то, что "количество пробелов" и термин "синтаксис" никак между собой не связаны по смыслу - ты не осилил:)

>Никаких причин им быть несвязаными нет - обоснований выше полно на всякий вкус.

Да, понимаю, очень трудно что-то уяснить в этой области, если даже классическое определение "синтаксиса" неизвестно (или "не дошло") :(

>О знаках препинания в книжке (вместо "символов пробела") ты "скромно умолчал" - выбросил из цитирования, как "неудобное"

(повторение) Я тут много раз показал, что "знаки препинания" ничем не хуже "отступов" для этих задач, если их хватает. Потому выбросил не как "неудобное" а "бессмысленное" - что толку пятый раз говорить о том же.

>. Сюрприз?:)

В каком редакторе? Установленые у меня Emacs и Vim ведут себя очень пошло.

>я всё равно ОФОРМЛЯЮ отступами так, что и без подсветки всё видно

(повторение) Это вредно - отображённая структура кода (отмеченая отступами) может быть не эквивалентна реальной(отмеченой {}), а скобки до сознания не дойдут. В результате ты прочтёшь не то, что написано.

>в его TeX'е любое количество пробелов считается за один

(повторение) Уверен? Как, интересно, literate haskell правильно печатается?

>классическое определение "синтаксиса" неизвестно

Тащи в студию определение, исключающее возможность использования "оформительских" элементов. Или сливаем?

>"знаки препинания" ничем не хуже "отступов" для этих задач, если их хватает

Наоборот, конечно тоже верно.

>В каком редакторе?

Навскидку - тривиальный kate

>Это вредно - отображённая структура кода (отмеченая отступами) может быть не эквивалентна реальной(отмеченой {}), а скобки до сознания не дойдут.

они отлично доходят до "сознания" транслятора/интерпретатора/компилятора - это во первых. А во-вторых - они дойдут (или не дойдут до "читателя" кода так, как Я (автор) указал, а если "читателю не понравится - он применит indent на своё усмотрение) - так понятнее?

>Уверен? Как, интересно, literate haskell правильно печатается?

1) Это ТЕБЕ задание.

2) "Прыжки" с перл на хаскель как раз и засчитываются ка "слив"... Но я не настолько жесток - пиши ещё - ты не безнадёжен.

>Тащи в студию определение

Определение "синтаксиса" ищи в школьной программе грамматики - я повторять школу тебе не собираюсь:)

> попробовал ввести в .pl файлике что-то типа

> if (1) { m/some{{{s/ ; print "more {{s"; # even more {{{s

> и посмотреть, что подсвечивает его любимый редактор при вводе последующих '}' ?

vim, emacs и joe подсвечивают тут всё правильно. Конечно же бывают ошибки в подсветке, но пример должен быть намного сложнее. А каким образом мы пришли к проблемам редактора вообще? Сам я до недавнего времени не пользовался подсветкой, и дальше бы в ней не нуждался, ну не виноват, что в joe внесли подсветку. :)

> Теперь подумай, что будет в той же ситуации с перловым кодом с несбалансироваными '{}' в регекспах, строковых литералах, коментариях, и ошибках синтаксиса. Тебе понадобится полноценный синтаксический разбор. Что намного сложнее простого :set foldmethod=indent.

Ты сам себе жутко противоречишь. То тебе пробелы полноценные символы, то специальные. Подумай, что произойдет, когда в многострочечном стринге или комментарии появится конец строки и пробелы/табы. Так что твой аргумент аннулируется, значимые переводы строк и пробелы ничем не легче для синтаксического анализа, чем {}.

В догонку. Многие могли бы написать такой код на Perl:

sub show_usage {
        print <<ENDUSAGE;
$0 [OPTIONS] IN_FILE [OUT_FILE]

Options:
        -h, --help      - show this usage and exit
        -v, --version   - show version and exit
        -d, --debug     - show debug output

You may specify url instead of local IN_FILE.
ENDUSAGE
        exit 0;
}

Некоторые могли бы даже написать подобно такому:

sub show_usage {
        (my $message = qq{
                $0 [OPTIONS] IN_FILE [OUT_FILE]

                Options:
                       -h, --help      - show this usage and exit
                       -v, --version   - show version and exit
                       -d, --debug     - show debug output

                You may specify url instead of local IN_FILE.
        }) =~ s/\t{1,2}//gm;
        print $message;
        exit 0;
}

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

Пример того, как бы ты написал эту функцию на Python в студию.
И объяснение того, как бы твой редактор разобрался в начальных
отступах, не производя полного синтаксического разбора кода.

>Навскидку - тривиальный kate

У меня его нет, т.ч. верю на слово. Теперь ещё скажи, что это реализуется без встроеного туда синтаксического анализатора - и слив защитан:-)

>они отлично доходят до "сознания" транслятора

Текст программы предназначен для людей.

>он применит indent на своё усмотрение

Т.е. полноценная поддержка синтаксиса в редакторе(или перед ним) всё таки является обязательным условием эффективной работы с не-отступническим синтаксисом. А с отступническим - необязательным.

>"Прыжки" с перл на хаскель как раз и засчитываются ка "слив"

Похоже ты всё таки туп:-(. Я уже 3й(а то и 4й) раз в этом споре говорю, что спор _не_ об perl vs python.

>Определение "синтаксиса" ищи в школьной программе грамматики

Слив не засчитан - школьная грамматика не изучает ни синтаксисы ни языки. Она изучает конкретный синтаксис 2-3х конкретных языков, и те на ненаучном уровне "это нужно запомнить".

>А каким образом мы пришли к проблемам редактора вообще

Это началось с вопроса определения читателем контекста строки 42, идущей на большим уровне вложености и после 20+20 строк кода уровня на 2 с лишним больше. Я сказал, что foldmethod=indent решает это проблему при гораздо более тривиальных возможностях редактора, по сравнению с требуемыми для поддержки "свободноформатируемых" синтаксисов.

Проблема тут не в подсветке синтаксиса а в поиске соответствующей скобки (% в виме) для той же цели - узнать, какой блок закончился этой '}'. На самом деле задача нетривиальна - мало того, что редактору придётся разбирать синтаксис, ему придется делать это с _недописаным_ текстом, т.е. который синтаксису формально _не_ соответствует.

>Теперь ещё скажи, что это реализуется без встроеного туда синтаксического анализатора - и слив защитан

Защитывай:) Мне как-то пофиг: есть там анализатор или нет, есть "подсветка или нет" - и без них обхожусь, мне как-то вполне комфортно тексты читать одноцветные (с того момента, как в детстве читать научился), книжки обычно одним цветом написаны (хотя, может уже делают разноцветные книжки и с разным количеством пробелов вместо знаков препинания - для блондинок и пайтонистов?:))

>Текст программы предназначен для людей.

Да неужели?! Чтоб визуально транслировать в машинный код?:)

>>он применит indent на своё усмотрение

>Т.е. полноценная поддержка синтаксиса в редакторе(или перед ним) всё таки является обязательным условием эффективной работы с не-отступническим синтаксисом.

В 18-й (?) раз повторяю двоешнику - "отступничество" не имеет никакого отношения к классическому термину "синтаксис". Даю подсказку: термин "синтаксис" - не прерогатива ТОЛЬКО языков ПРОГРАММИРОВАНИЯ:) Ты в школе учился или ЕЩЁ нет?:)

>Я уже 3й(а то и 4й) раз в этом споре говорю, что спор _не_ об perl vs python.

Не 3-4-й, а постоянно: то у тебя редактор - неотъёмлимая часть языка, то ты про перл, то про хаскель. то Д.Кнут для тебя не авторитет (ну это простительно - юношеский максимализм:))

>Слив не засчитан - школьная грамматика не изучает ни синтаксисы ни языки.

Грамматика - не, не изучает. Школьники в курсе грамматики - изучают... или не изучают (как ты):)

>Она изучает конкретный синтаксис 2-3х конкретных языков, и те на ненаучном уровне "это нужно запомнить".

Ты путаешь грамматику с лингвистикой:) Теперь я почти уверен, что больше тройки по 5-бальной шкале по диктанту/сочинению/изложению у тебя не было :(

>Ты сам себе жутко противоречишь

Это я тебе противоречу. Ты утверждал, что определение начала удлённого блока в "индентоориентированом" синтаксисе сложнее чем в "свободноформатном". Я утверждаю обратное - оно _не_ сложнее, и часто проще.

>что произойдет, когда в многострочечном стринге или комментарии появится конец строки и пробелы/табы

Это вопрос к конкретному синтаксису. Я не утверждал, что какой-то из существующих языков делает это достаточно удобным. Вопрос вероятностей - чаще всего внутри строковых литералов и многострочных коментариев лежит _не_ код на целевом языке, и следовательно читатель обнаружит неправильность поведения редактора. А вероятность встретить {} там же достаточно велика, и "правильное" их количество может привести к тому, что, скажем после '%' вим уйдёт именно на '{' в коде, и его ошибку будет не так легко заметить.

Опять вывод - потенциальная читаемость синтаксисов с отступами лучше.

>>А каким образом мы пришли к проблемам редактора вообще

>Это началось с вопроса определения читателем контекста строки 42, идущей на большим уровне вложености и после 20+20 строк кода уровня на 2 с лишним больше.

"Поколение чупа-чупс", блин... Они считают, что тексты бывают ТОЛЬКО на экране монитора... Старик Гутенберг для них тоже уже не авторитет... :(

>Теперь я почти уверен, что больше тройки по 5-бальной шкале по диктанту/сочинению/изложению

Это пожалуй единственное, что в твоём опусе не словесный понос. Были у меня такие оценки по украинским сочинениям:-)

>потенциальная читаемость синтаксисов с отступами лучше.

У синтаксиса нет читаемости, читаемость есть у текста (в т.ч. и текста программы).

>Пример того, как бы ты написал эту функцию на Python в студию

Мы начинаем холивор за python vs perl? Это неинтересно. (я бы делал либо с теми же регекспами(дословный перевод перлового), либо конкатенацией строковых литералов).

Я пытался убедить тебя _не_ в преимуществах питона а в эффективности отступов для выделения синтаксических блоков.

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

>Старик Гутенберг для них тоже уже не авторитет.

Ты когда в прошлый раз книгу держал в руках? Там текст тоже на "плоскости" расположен. Сюрприз?

>Ты когда в прошлый раз книгу держал в руках? Там текст тоже на "плоскости" расположен. Сюрприз?

И с "подсветками" и "отступами"? Значит всё таки есть такие книжки для блондинок и "пайтонистов"?!:)

> Вопрос вероятностей - чаще всего внутри строковых литералов и многострочных коментариев лежит _не_ код на целевом языке, и следовательно читатель обнаружит неправильность поведения редактора. А вероятность встретить {} там же достаточно велика, и "правильное" их количество

Из моего опыта, довольно редко в стрингах появляются "{", и уж практически никогда без парной "}". В то же время, все мои скрипты имеют как минимум функцию show_usage с начальными отступами в стринге. Твой аргумент для меня просто неверен.

> Опять вывод - потенциальная читаемость синтаксисов с отступами лучше.

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

Всё-таки покаместь из _рассмотренных_ реальные проблемы у редакторов всё же с синтаксисом Питона, а не Перл. Так что вовсе непонятно, существует ли хотя бы одно преимущество на фоне массы недостатков у такого ущербного синтаксиса

>И с "подсветками" и "отступами"

Держись крепче - они там _используются_ и именно для структурирования текста. Только "подсветка" заменена размером/стилем шрифта. Возможно в той эротической прозе, которую ты читаешь, оно не так уж и нужно, но в любой более-менее серьёзной (нехудожественной) книге ты увидишь этого целую кучу.

>в любой более-менее серьёзной (нехудожественной) книге ты увидишь этого целую кучу.

"серъёзная нехудожественная книга" - это "любовные романы" для блондинок?:)

>Из моего опыта, довольно редко в стрингах появляются "{"

А я однажды бросил писать что-то связаное с конфигом, использующим '{}' по причине дикого поведения редакторов на перловом коде c {} в данных :-)

>Синтаксис должен быть однозначным

Он однозначен. На самом деле игры с отступами (и стеком) могут закодировать 3 символа - (отступ < | = | > сохранённого в стеке). Это и делают - к удовольствию и негодованию програмистов. Потом при чтении они ставят "настоящие" символы на место - напр. haskell заменяет "отступ" (соответственно) на '}'(сколько нужно) или ';', или ничего (увеличение отступа там значит продолжение строки), и добавляет '{' в определённых местах. То же в питоне - только символы отличаются.

>читабельность же его опциональна

Категорически возражаю. Чтение - наиболее частая операция, проводимая человеком над текстом программы. Соотв. она критична.

>читабельность Питона ... не может быть улучшена программистом ... гибкого синтаксиса может быть поднята

Я рассматриваю это с другой стороны - читабельность программы с жестким синтаксисом труднее ухудшить, не испортив программу. Если же провести операцию по замене '{' ';' '}' на соответстующие отступы > == <, читабельность программы _не_ ухудшится (да, '}}}' выглядят не лучше IMO).

>Всё-таки покаместь из _рассмотренных_ реальные проблемы у редакторов всё же с синтаксисом Питона, а не Перл

Извини упрямца, я всё-таки предпочту верить своим глазам, а не твоим словам.

>массы недостатков у такого ущербного синтаксиса

Итак до сих пор собрали массу из 2 недостатков - порчу при удалении пробелов (что мне удалось обосновано назвать преимуществом:-) и проблему идентификации блока при _чтении_ программы в местах, соответствующих '}}}}}', с чем справляется _тривиальный_ foldmethod=indent, а если не справляется - это заметно невооружённым глазом.

На фоне таких недостатков возникает вопрос об определении термина "преимущество":-)

Слив защитан.

>при чтении они ставят "настоящие" символы на место

"они" это парсеры, конечно.

А насчёт того, что "Синтаксис должен быть ... гибким"

1. зачем гибкость синтаксиса такому ограниченому языку, как питон?

2. и в общем то он не должен быть гибким. Попробуй обосновать обратное чем-то кроме "крутые хакеры хотят". Гибкость синтаксиса нужна только для того, чтобы "красивее" выражать те мысли, которые взбрели в голову. А выражать их "красиво" имеет смысл только если это кому-то читать. И мы возвращаемся к проблеме "читабельности", которая, как мы выяснили, почти никогда не теряется при замене '{}' на соответствующие отступы.

> А я однажды бросил писать что-то связаное с конфигом, использующим '{}' по причине дикого поведения редакторов на перловом коде c {} в данных

Охотно верю, что ты выбираешь себе программистскую задачу под нужды своего редактора, а не редактор под нужды программистской задачи. Вполне очевидно, что плохо настроенный (или слишком заумный) редактор может мешать нормальной работе, только это не аргумент, просто выключи заумность или смени редактор.

> Он однозначен. На самом деле игры с отступами (и стеком) могут закодировать 3 символа. [...] То же в питоне - только символы отличаются.

В том-то и дело, что не могут однозначно закодировать 3 символа. Как, например, по-твоему в Питоне представляется такая неоднозначная программа:

if 1:\n<4 probela>print 1\n<2 probela>else:

Ущербный, шаткий (разная семантика в разных контекстах), и неоднозначный синтаксис, что и говорить.

> зачем гибкость синтаксиса такому ограниченому языку, как питон?

Так не все с этим согласны. Некоторые (например, ESR) проектируют Питон как язык общего назначения юникс.

> мы возвращаемся к проблеме "читабельности", которая, как мы выяснили, почти никогда не теряется при замене '{}' на соответствующие отступы

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

Посмотри на "Source" в уже приводимой ссылке:

http://search.cpan.org/dist/Acme-Bleach/lib/Acme/Bleach.pm

Там все короткие функции - в одну строку, но от этого менее читаемыми не стали. Конечно же всё, что в namespace Acme - один сплошной прикол и fun, но сказка ложь, да в ней намёк.

>Охотно верю, что ты выбираешь себе программистскую задачу под нужды своего редактора

Я выбираю задачу под удовольствие от её решения. Тогда не сильно нужно было, а раздражало сильно. 
Когда следующий раз понадобиться я её на хаскеле с парсеком сделаю.

>В том-то и дело, что не могут

Почитай, что ли описание. Зачем ты споришь с фактами.

>такая неоднозначная программа: 
if 1:
    print 1
  else:

Это _однозначно_ _не_ программа на питоне(тебе об этом с радостью сообщит парсер). Как тебе такой код на перле:

f x | x == 1 = 1
    | otherwise = 2

Это _не_ перл, т.ч. нечего на синтаксис пенять, коли текст кривой.
Ты бы думал, перед тем как писать.

>... Питон как язык общего назначения юникс

"Язык общего назначения" это _не_ язык, на котором положено 
писать _все_ программы. 

>Для меня красиво отформатированный код использующий {}

Так бы и говорил - "для меня критерием красоты является использование {}"
С этим не поспоришь :-) Очевидно, что в красиво отформатированом коде
три видимых символа можно выбросить, заменив их сравнением отступов.
Так вай жеж нот?

>учитывающий специфику задачи

Опять - _где_ обоснование того, что на языке с отступами нельзя учесть
специфику задачи? Сколько таких задач ты видел?

>Да и для машины тоже (не нужно неправильно гадать, что имел ввиду программист)

Покажи мне хоть один _правильный_ питонский код, в котором парсеру 
пришлось бы гадать, что имел ввиду программист. 

>Там все короткие функции - в одну строку, но от этого менее читаемыми не стали

А _более_ читаемыми стали? Сравниваем (заменив {;} отступами и \n):

sub whiten { local $_ = unpack "b*", pop; tr/01/ \t/; s/(.{9})/$1\n/g; $tie.$_ }

sub whiten
  local $_ = unpack "b*", pop
  tr/01/ \t/
  s/(.{9})/$1\n/g
  $tie.$_ 

Отличие 2го варианта в том, что не приходится спотыкаться глазами
о каждый знак, с целью определить "а не [{;}] ли он".

Ты вместо того, чтобы думать, что ты один тут умный, а все глупые, почитал бы мой аргумент. Ты сказал, что отступы могут однозначно закодировать 3 символа, я привёл пример, когда они не могут быть переведены в символы начала и конца блока. Получаем неоднозначность синтаксиса. Причем на каждом отдельном экране редактора всё может выглядеть прекрасно, а программа - незаконна. И чем тогда тебе редактор поможет, всё же прекрасно читаемо?

> Очевидно, что в красиво отформатированом коде три видимых символа можно выбросить, заменив их сравнением отступов.

Нельзя их просто так выбросить, не выбросив также красоты. Где твоё осуществление show_usage?

> А _более_ читаемыми стали?

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

Запутаный, размашистый (или наоборот скомканый, в зависимости от вкуса), неоднозначный, плохо навигируемый, неприспособленный для определений стрингов inline, таки использующий {}, [], (), что абсолютно не сочетается с законами отступов, не дающий явно увидеть где выражения (короткие и многострочные) кончаются, негибкий - это всё да, а вот читаемый ли - нет.

>я привёл пример, когда они не могут быть переведены в символы начала и конца блока

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

>всё может выглядеть прекрасно, а программа - незаконна

if a == b: print 'OK'

тоже вполне читаемо. Но перл этого не поймёт. Это значит перловский синтаксис неоднозначен?

>Где твоё осуществление show_usage

Ну если ты настаиваешь на мерянии show_usage-й то сейчас нарисую.

>Если функция помещается на строку, а вся программа - на один экран

Вот мы и нашли нишу для кривоскобочных синтаксисов:-)

>Питон не даёт никаких опций в выборе вариантов читаемости

by design, однако. Они даже то, что осталось, хотят убрать.

>я не могу согласиться, что тот единственно возможный тип записи читаем в общем случае

Если не определить "общий" как "наиболее вероятный".

>Запутаный,...а вот читаемый ли - нет

Честно говоря не понял к чему это относится. Ты всё таки о питоне споришь? Бог в помощь.

У кого show-usage толще

Чем плох такой:

#!/usr/bin/python
# encoding: utf-8
'''usage: тут текст

   как хочешь красиво
       форматированый

'''
def show_usage():
  print __doc__
  raise SystemExit,1

Я ему о том, что его собственное утверждение "последовательность пробелов в строках может быть переведена в последовательность открыл блок, продолжил блок, закрыл блок" - неверно (в отличии от аналогичного с помощью "{", ";", "}"), а он мне другие языки приводит, и ещё с таким умным видом...

> Чем плох такой.

То есть ты для каждой функции, которую тебя попросят написать выделишь отдельный файл, чтобы в нём на верхнем уровне один единственный стринг определить? Такое решение не катит, придется стринг в самой функции определять, хочешь или нет. Вперёд, я потом на этот пример буду ссылаться, когда мы будем рассматривать читаемость, консистентность, тривиальность определения уровней, и многого подобного.

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

Кстати, чтобы мне легче было бы судить о твоем понимании красоты,
неплохо бы взглянуть как ты отформатируешь в питоне аналог следующего:

$patterns = {
        spaces_sux => {
                name => "problems regarding spaces for indentation",
                pages_on_the_subject => [
                        [1, 5],
                        [20, 21],
                        [55, 66],
                ],
        },
        tabs_the_way => {
                name => "advantages on using tabs-only for indentation",
                pages_on_the_subject => [
                        [7, 9],
                        [40, 41],
                ],
        },
};

>как ты отформатируешь в питоне аналог следующего

А вот точно также. Только отступы меньше, => заменить на : и то, что до него засунуть в ''. Получиться почти то же - тут питон недоработан IMHO. Будь я Гвидом я бы выбросил из того, что получилось ещё 5 символов: ,[]{} , используя для описания таких структур что-то типа YAML-а.

>То есть ты для каждой функции

1. У тебя есть программа, в которой больше одной функции выводят usage и завершаются?

2. Регулярные выражения из твоего второго примере в питоне есть. Сам s/.../.../ на re.sub заменить не сможешь? Впрочем, я бы не изобретал велосипед - from pydoc import text и замени в своём тексте X ~= s/.../gm на text.indent(X), поубирай скобки, и сравнивай.

>последовательность пробелов в строках может быть переведена в последовательность открыл блок, продолжил блок, закрыл блок - неверно

Ладно, раз ты такой ленивый цитирую из питона:

Before the first line of the file is read, a single zero is pushed on the stack; this will never be popped off again. The numbers pushed on the stack will always be strictly increasing from bottom to top. At the beginning of each logical line, the line's indentation level is compared to the top of the stack. If it is equal, nothing happens. If it is larger, it is pushed on the stack, and one INDENT token is generated. If it is smaller, it must be one of the numbers occurring on the stack; all numbers on the stack that are larger are popped off, and for each number popped off a DEDENT token is generated. At the end of the file, a DEDENT token is generated for each number remaining on the stack that is larger than zero

Очевидно 2 символа генерируются, место третьего там, где "nothing happens" - там всё-таки что-то происходит.

PS

Где неоднозначность то?

> Где неоднозначность то?

Нельзя однозначно в "{", "}" перевести, существуют половинчатые (незаконные) состояния, которые в нормальных синтаксисах не существуют. Существует также на порядки больше вероятность ошибки в таком синтаксисе, так как правильность зависит от всех (тысячи) предыдущих строк блока, вместо того чтобы зависить лишь от уровня (количество которых единицы).

>Нельзя однозначно в "{", "}" перевести

Ещё раз: неправильный текст нельзя. Правильный - можно.

>cуществуют половинчатые (незаконные) состояния, которые в нормальных синтаксисах не существуют

Незаконных конструкций в любом синтаксисе бесконечное число.

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

Опять лжёшь.

1. ошибка обнаруживается на _первом_ неправильном инденте. Сравни с перлом - там она обнаруживается на месте недостаточного/избыточного }.

2. Ты читал цитату? Входной поток парсера состоит из строки текста и стека, размер последнего равен уровню(+1?). Где тут зависимость от тысячи?

И после таких твоих заявлений ты удивляешься моим подозрениям в твоей неадекватности?

> А вот точно также. Только отступы меньше

Так задай tabsize=2 и будет тебе (и главное другим, кто любит отступы пошире) счастье.

> Получиться почти то же - тут питон недоработан IMHO.

Как раз наоборот. Это с значимыми отступами он недоработан (или перемудрен). Везде, и в inline стрингах и в данных, наличие ограничителей "начало структуры/стринга/блока" и "конец" является крайне необходимым. Иначе придется урезать всю функциональность, чтобы парсер не запутался. Как по-твоему должен выглядеть такой код в твоём синтаксисе?

$is_success = $client->send( message => "join #$channel", callback => sub { $log->add_line(@_) }, user_info => { name => "Donkey", timezone => [ +3, 0 ] }, timeout => 10, ) == STATUS_OK;

Такое впечатление, что мы говорим на разных языках.

> Где тут зависимость от тысячи?

Зависимость в том, что я не могу написать строку номер 3000 не обратившись к строке номер 2000 и не скопировав индентацию из неё. Вместо того чтобы просто поставить "}" и продолжить.

Хоть на правильность никак не влияет, оригинально этот вызов функции выглядел как:

$is_success = $client->send(
        message => "join #$channel",
        callback => sub { $log->add_line(@_) },
        user_info => { name => "Donkey", timezone => [ +3, 0 ] },
        timeout => 10,
) == STATUS_OK;

> У тебя есть программа, в которой больше одной функции выводят usage

Мы говорили о стрингах в функциях, однострочных и многострочных, коих в моих программах полно. И для этого мне не проходится создавать новый файл на каждую функцию и определять глобальный стринг на верхнем уровне. Впрочем это лишь очередное (десятое?) ограничение Питона, вызванное его крайне проблематичным синтаксисом.

Начнём с конца

>И для этого мне не проходится создавать новый файл на каждую функцию

Если ты не заметил, ты предложил аж 2 перловых способа получить правильно форматированую программу с правильно отформатироваными строковыми литералами (которые ты называешь стрингами). Первый работает только для 0-го уровня, второй использует команду s/// для убирания ненужных индентов. Я тебе привёл 3 питонских - 2 из которых _точно_ эквивалентны твоим с точностью до синтаксиса регекспа. Каким образом из этого следует "проблематичность" синтаксиса - не понятно.

>Вместо того чтобы просто поставить "}" и продолжить

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

>Как по-твоему должен выглядеть такой код в твоём синтаксисе

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

Примерно так вот

is_success = STATUS_OK == client->send hash
  'message', 'join #$channel'
  'callback', sub
    log->add_line($@)
  'user_info', hash
    'name','Donkey'
    'timezone', list (3,0)
  'timeout', 10

Если для запутывания читателя STATUS_OK хочется перенести вниз, 
понадобится () перед первым 'hash' и '==' соответственно.

Как это может работать: 
увеличение отступа добавляет в поток '<APPLY>((' и новый уровень в стек, 
равный отступ - '),(', 
уменьшение '))' для каждого вынимаемного из стека значения, пока отступы не сравняются. 
<APPLY> - высокоприоритетный инфиксный оператор, вызывающий функцию (левый аргумент) 
с аргументом (список/tuple справа). 
a b c - вызов ф-ии 'a' с аргументами 'b' 'c', приоритет чуть ниже '<APPLY>'. 
Запятая - низкоприоритетный конструктор tuple-ов. 
Скобки как обычно означают группировку для ухода от умолчательных приоритетов.

list, hash, sub - "конструкторы" соответствующих структур, 
работающие на этапе компиляции.

Что мы таким образом сделали невозможным?