История Python. Принципы проектирования
Дальнейшие записи в этом блоге опустятся в окровавленные пучины истории 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. Разными способами, но в Python совершён сознательный уход от следующих идей:
- «ABC group» во всем стремилась к совершенству. Например, они использовали алгоритмы, где данные представлены древовидной структурой, и которые считаются оптимальными для асимптотически больших коллекций (при этом не так хороши маленьких).
- В «ABC group» хотели, насколько это возможно, изолировать пользователя от «большого и страшного мира компьютеров». Мало того что должны отсутствовать ограничения на диапазоны числовых значений, длины строк и размеры коллекций (не считая ограничения доступной оперативной памяти). У пользователей не должна была возникать необходимость работать с файлами, дисками, «сохранением» или другими программами. Эти стремления подвигли «ABC group» создать полностью интегрированную среду редактирования. (Конечно были возможности избежать ABC окружение, но, преимущественно, они были запоздалые и не были доступны напрямую из языка).
- В «ABC group» исходили из предположения о том, что пользователи ранее не имели опыта работы с компьютером (или были готовы забыть его). Поэтому была введена альтернативная терминология — более «дружественные к новичкам» стандартные термины программирования. Например, процедуры были названы «инструкциями» (how-tos), а переменные «положениями» (locations).
- «ABC group» разрабатывали язык ABC, не задумываясь о перспективах его развития, и не ожидая участия пользователей в его проектировании. Язык ABC был создан как закрытая система, безукоризненная настолько, насколько это удалось проектировщикам. Любопытство пользователей к тому, «что же там внутри», не поощрялось. И хотя были разговоры об открытии продвинутым пользователям части реализации, на более поздних стадиях проекта это так и не осуществилось.
Принципы проектирования, использованные мной при создании Python, вероятно, стали одной из причин его конечного успеха. Вместо борьбы за совершенство, люди, впервые использовавшие Python, сочли его «достаточно подходящим» для реализации их целей. Поскольку число пользователей росло, то предложения по улучшению постепенно вносились в язык. Как вы увидите из дальнейших записей, многие из этих улучшений повлекли существенные изменения и исправления в ядре языка. И даже сегодня Python продолжает развиваться.
Оригинал: The History of Python – Python’s Design Philosophy