Pull to refresh

Python, философия дизайна — Guido van Rossum (часть 1)

Reading time 5 min
Views 9.6K
image
Это первая часть статьи из официального блога автора любимого всеми нами языка. Поэтому повествование ведется от лица самого Гуидо ван Россума. Вторая часть здесь.

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

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

— Заимствовать идеи отовсюду, откуда это имеет смысл.
— “Вещи должны быть настолько простыми, насколько это возможно, но не проще этого.” (Эйнштейн)
— Если делать одну вещь — то делать хорошо («Философия UNIX»).
— Не заморачиваться по поводу производительности — можно будет оптимизировать в дальнейшем, если понадобится.
— Не бороться с железом, а просто плыть по течению.
— Не пытаться достичь совершенства, ибо “достаточно хорошо” — зачастую именно то, что нужно.
— (Таким образом) можно иногда срезать угол, особенно если ты можешь решить эту проблему позднее.

Остальные принципы не были настолько экономны по отношению ко времени. Иногда даже был прямо обратный эффект:

— Структура Python не должна быть привязана к конкретной платформе. Ничего, если часть функционала будет порой недоступна, но основа должна работать всегда и везде.
— Не грузить пользователя деталями, которые машина может решить самостоятельно (я не всегда следовал этому правилу, и некоторые катастрофические последствия от этого будут описаны далее).
— Поддержка и поощрение платформонезависимого кода, но не стоит обрезать доступ к специфическим возможностям платформы (Это, кстати, остро контрастирует с Java.)
— Большая сложная система должна иметь многоуровневую расширяемость. Это увеличивает возможность пользователей, как бы замороченно это не звучало, помочь самим себе.
— Ошибки не должны быть фатальными. Это значит, что код пользователя должен уметь пережить все, пока виртуальная машина еще способна работать.
— В то же время, ошибки не должны проходить незамеченными (последние две вещи действительно привели к решению использовать исключения во время структурирования).
— Ошибке в коде пользователя не должно даваться шанса привести интерпретатор Python к неправильной работе; падение ядра никогда не должно быть ошибкой пользователя.

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

Хотя я собираюсь чуть попозже рассказать более подробно о влиянии опыта из ABC на развитие Python, мне бы хотелось упомянуть одно правило относительно читаемости кода отдельно: знаки препинания должны использоваться «консервативно», в соответствии с их обычным использованием в письменном английском или алгебре высшей школы. Исключения должны касаться только вещей, ставшими традицией для языков программирования, как, например, “x*y” для умножения, “a[i]” для обращения в элементу массива, или “x.foo” выбора атрибута, но Python не использует ни “$” для обозначения переменных, ни “!” для обозначения отрицания в операциях.

Тим Петерс (Tim Peters), который долгое время был преданным пользователем Python, а потом стал самым плодовитым и цепким его разработчиком, предпринял попытку объединить мои разрозненные принципы структурирования в нечто, что он назвал «Дзен Python». Приведу его здесь во всей полноте:

— Красота лучше уродства.
— Ясность лучше неясности.
— Простота лучше сложности.
— Сложность лучше запутанности.
— Плоскость лучше вложенности.
— Разведенность лучше концентрированности.
— Читаемость ценится высоко.
— Особые случаи не настолько особы, чтобы ради них нарушать правила.
— Хотя практичность выше опрятности.
— Ошибки не должны проходить незамеченными.
— Если ошибка не в незаметности.
— Перед лицом неопределенности лучше отказаться от попыток угадать.
— Должен быть один — и было бы идеально, если только один — очевидный способ решить проблему.
— Хотя на первый взгляд этот способ может и не казатся очевидным, особенно если вы — голландец.
— Сейчас лучше, чем никогда.
— Хотя зачастую никогда лучше, чем прямо сейчас.
— Если структуру непросто объяснить — то это плохая идея.
— Если структуру просто объяснить, это может быть хорошей идеей.
— Области имен — это действительно чертовски хорошая идея — сделаем их побольше!

Хотя мой опыт в ABC оказал большое влияние на Python, ABC group имела свои принципы структурирования, которые радикально отличались от питоновых. Во многом Python сознательно серьезно отходил от них:

— ABC group стремились к совершенству. Например, они использовали алгоритмы с использованием древовидных структур данных (асимптотически оптимальные, но не очень быстрые для небольших объемов).
— ABC group хотели отделить пользователя, насколько это вообще возможно, от “большого злого мира компьютеров”. Не должно быть не только предела размерам чисел, длине строк, или размеру наборов данных (конечно, в рамках общей доступной памяти), но пользователям также должно быть не нужно ковыряться в файлах, дисках, “сохранениях” или других программах. ABC должно быть единственной вещью, которая им нужна. Этот постулат также привел ABC group к созданию полного комплексного инструмента редактирования окружения, уникального для ABC (Конечно, было возможно «выбраться» из окружения ABC, но это было лишь второстепенным, и не рассматривалось с точки зрения самого языка.)
— ABC group полагали, что пользователи не обязаны иметь никакого компьютерного опыта (или желали его потерять ( :) — Прим. переводчика)). Таким образом, альтернативная терминология, как они полагали, должна была привести к структуре, более “дружелюбной для новичков” чем в других языках программирования. Например, процедуры (procedures) были названы «руководствами»(“how-tos”), а переменные (variables) — “путями”.
— ABC group структурировали ABC без особых планов развития, и без особой надежды на поддержку со стороны пользователей. ABC была создана как закрытая система, настолько безупречной, насколько сами разработчики считали ее таковой. Попытки пользователя “заглянуть под покрывало” не поощрялись. Хотя был разговор об открытии особых разделов структуры системы «для продвинутых пользователей», в дальнейшем это так и не было реализовано.

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

(с) Guido van Rossum
Tags:
Hubs:
+66
Comments 22
Comments Comments 22

Articles