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

    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
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 22
    • 0
      замечательно, спасибо за перевод. я прочитал и оригинал, но многим пригодится.
      • +1
        FYI: углы скорее срезают, чем сокращают.
        • +2
          точно. тем более, что там cut. исправил.
        • +7
          Здорово! Сегодня хабр так и радует обилием информации о питоне!
          • +1
            > Насколько я помню, второе будет введено в новой версии языка, Python 3000
            • +1
              да, а что не так? А еще суп и компот.
              • 0
                Извините, отправка сообщения сглючила.
            • 0
              > Насколько я помню, второе будет введено в новой версии языка, Python 3000

              Python 3000 уже вышел (2 декабря), и там нет «укороченных» булевых операций… Спасибо за статью, популяризация Python — хорошее дело.
              • 0
                Я имел в виду С-образный способ сравнения: a != b работает в Python 3.0, вместо a <> b.
                • 0
                  Так оно работает и в предыдущих версиях.
                  • 0
                    Хм, значит, ошибся :) Прошу прощения
                  • 0
                    так это и в 2.5 работает.
                • 0
                  Хабр сегодня прям радует питонеров. Я вчера подписался на python-history, собирался сегодня вечером почитать. А тут такое! Спасибо!
                  • 0
                    > Например, они использовали структуру дерева для своих алгоритмов

                    В оригинале: they used tree-based data structure algorithms

                    Я в оригинале эту фразу не понял. В переводе тоже.
                    • 0
                      все было основано на алгоритмах ветвления. То есть if-else и switch-case. Думаю, так.
                      • 0
                        Вот не знаю, не знаю. Пытаюсь сейчас выяснить.
                        • +2
                          Возможно, «они использовали древовидные структуры данных». Слово «алгоитмы» тут немного лишнее. В таком варианте звучит вполне логично.
                          • 0
                            ну просто слово algorithms все-таки должно быть как-то вписано в контекст… пусть пока останется.
                      • +2
                        For example, they used tree-based data structure algorithms that were proven to be optimal for asymptotically large collections (but were not so great for small collections).

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

                        Как-то так.

                        Или «алгоритмы на деревьях», или «алгоритмы с использованием деревьев/древовидных структур данных».

                        • 0
                          Да, это вполне подходит по смыслу.
                          • 0
                            Сдаюсь, доктор Форман. Плюс один :)
                        • НЛО прилетело и опубликовало эту надпись здесь

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