Почему Python не требует точно четырех пробелов на уровень отступа?

Еще один случай, с которым я только что столкнулся в списке рассылки tutor@python.org - Слепой программист, работающий на Python, использует программу для чтения - по-видимому, программа чтения не очень любит несколько пробелов, поэтому ему проще использовать один пробел.

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

Важность пробелов не является проблемой для большинства людей по нескольким причинам. Во-первых, я не могу придумать ни одного (хорошего) программиста, который бы утверждал, что правильное форматирование кода — это плохо. Секундалогика требует, чтобы мы разделили наш код на блоки. Во многих языках используются разделители {}. В сборке это обычно этикетки. Выбор пробелов Python на самом деле довольно естественен, по крайней мере, для английского языка. Когда вы читаете книгу, газету или сообщение в блоге, когда кто-то делает цитату, она обычно имеет отступ. Абзацы разделяются пустой строкой или двумя. Главы обычно разделяются пустым пространством в конце страницы и пустым пространством в начале следующей. Таким образом, пробелы — это хорошо, но принуждение программистов придерживаться вашего конкретного стандарта заставит программистов заняться чем-то другим со своим временем.

Антология Джоэла Лучшее написание программного обеспечения начинается с интересного и провокационного эссе Кена Арнольда «Стиль - это субстанция», из сообщения Кена вы также можете прочитать здесь . Это хорошо аргументированное эссе с тезисом, и я цитирую, что «единственный способ добраться от того места, где мы находимся, к месту, где мы перестаем беспокоиться о стиле, - это сделать его частью языка».

Это единственное эссе, которое я когда-либо читал, в котором предлагается, чтобы компиляторы языков блокировали каждый аспект стиля (например, ваша идея о блокировке отступов будет частью этого - - не только в Python ... Основные прошлые вклады Кена - это Jini, curses, javaspaces, rogue и части Corba, ничего связанного с Python). Это действительно хорошие аргументы, и в комментариях к онлайн-версии вы можете увидеть некоторые контрапункты (увы, не обязательно аргументированные так же хорошо).

Мне кажется ироничным, что один респондент говорит о «Фортране и его строгих правилах форматирования»; Это звучит так, как будто кто-то никогда не использовал Фортран или использовал его с очень поверхностным и маргинальным пониманием этого. На скольких языках вы знаете, где можно писать, например,

total count = 1 000 000

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

Конечно, гибкость стиля всегда сопряжена с риском ошибок, например, в случае с Фортраном

DO 10 I = 1. 5

присваивает переменной DO10I число 1,5, в то время как почти неразличимый

DO 10 I = 1, 5

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

Так что, пожалуйста, не берите Фортран в качестве примера ни за, ни против "блокировки", потому что во многих стилистических аспектах это невероятно безвыходно!

Некоторые примеры блокировки включают современные языки, например соглашения о регистрах и сделать их принудительными частями языка (инициалы в верхнем регистре для классов и т. неклассный с прописной. Я думаю, что полученное принудительное единообразие - это хорошо, и я не понимаю, почему оно должно отличаться, если принудительный аспект стиля - это интервал, а не регистр и т. Д. Да, Арнольд в основном убедил меня в этом ;-).

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

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

Я искренне верю в это.

Python очень удобен.

Помимо причин, указанных выше, есть еще одна действительно веская причина, по которой вы хотите, чтобы интерпретатор поддерживал минимальные отступы: экономия места. Из-за ограничений, связанных с замораживанием байт-кода Python, не всегда практично отправлять что-то только с файлами .pyc вместо фактического кода. Это означает, что если вы пишете код для работы на платформе с очень ограниченным пространством (скажем, маршрутизатор OpenWRT), имеет смысл свести количество пространств к минимуму для экономии места на диске.

Вот почему я написал пиминификатор

reindent.py изменяет любой файл python на использование 4-пробельных отступов и без жестких символов табуляции. Наличие этой удобной утилиты избавляет от необходимости заставлять других программировать Python в стиле 4-х пробелов.

PS. Программисты Perl, Java, C проводят много мозговых циклов, возясь с синтаксическими ошибками, связанными с точкой с запятой. Каждый цикл мозга, потраченный впустую на синтаксическую ерунду, - это цикл, который не тратится на решение реальных проблем программирования. Одним из преимуществ Python для быстрой разработки является то, что он сводит к минимуму синтаксические правила, которые в конечном итоге тратят мозговые циклы. Поэтому меньше требований к синтаксису лучше, чем больше.

Несмотря на то, что требования согласованного отступа в пределах одного блока связаны с необходимостью, нет последствий, связанных с одинаковыми или разными уровнями отступов между блоками. Другими словами, в чем будет смысл?

Сравнение его с требованием к пробелам на самом деле недопустимо, потому что пробелы являются частью синтаксиса Python: они определяют область видимости. Если область видимости может быть определена однозначно, почему нам все равно, сколько пробелов используется для ее определения? Какую пользу принесет принуждение всех использовать некоторое (совершенно произвольное) фиксированное количество пробелов?

Что, если бы ваш текстовый процессор заставлял вас делать абзацы ровно четырьмя пробелами? Это будет раздражать и бесполезно. Он не должен служить цели иметь фиксированное количество пробелов для отступа.

Подумайте об этом так: Python не столько требует «пробелов», сколько требует, чтобы вы нашли способ определить область действия без фигурных скобок. То, что выпало из этого, было пробелом, и сказать, что у него есть `` требование пробелов '', проще и очевиднее, чем сказать, что у него есть требование `` определение области действия без скобок '', поэтому для краткости мы просто говорим, что у него есть `` пробел требование '; -)

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

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

Использование 1 пробела (или табуляции) экономит место во время игры в код-гольф :-p

Смотрите PEP 666 - Отказ от глупых отступов

Чтобы избежать проблем, которые возникают с требованием make иметь символы табуляции перед каждым действием.

Например, очень неприятно, если символ табуляции равен четырем пробелам, а вы перелистываете туда-сюда файл .c и Makefile