Автор оригинала: Abdur-Rahmaan Janhangeer.
Дзен Питона впервые увидел свет в 1999 году. Это один из многих аспектов, который добавляет удивительности Python. Это набор выражений, отражающих дух языка. Это было объявлено Тимом Питерсом, авторитетным инженером-программистом, мастером Pythonista и “самым плодовитым и цепким разработчиком ядра Python”, по словам не кого иного, как Гвидо [18]. Эта статья основана в основном на высказываниях основных разработчиков и очень авторитетных членов. Это отличный подарок всем тем, кто интересуется историей скрипта sysadmin, который застал мир (приятным) сюрпризом.
Путь, которым пришел Дзэн, был уникален. Это было отражение от неизвестного Патрика Фалена о чувстве Питона [1]:
.. чем больше я использую и узнаю о языке, тем больше я ценю хороший баланс и вес, который Гвидо дал ему. Тем не менее, кажется, нет ни одного документа, который суммировал бы эту “эстетику”, но, скорее, она имеет тенденцию появляться по частям, с течением времени, в основном в Мудрости председателя Тима.
Это был призыв вселить дух Питона в пришельцев с Земли Перл и за ее пределами. Он запросил от 10 до 20 строк, которые суммируют представление Python
Были бы и Гвидо, и Тим Питерс готовы сотрудничать над короткой статьей-назовите ее “Путь Python” за неимением лучшего названия-в которой излагаются 10-20 предписаний, которые они могли бы предложить тем, кто приходит в Python из других языков и сразу же хочет найти способ согнуть его в неудобные позиции – (реализовать замыкания и т. Д.).
Это была просьба не допустить, чтобы питонисты впали в ошибку, агитируя за изменение языка. Он выступал за то, чтобы проникнуться потоком языка и изменить свои пути и взгляды, а не наоборот. В оригинальном письме он цитировал Фредрика Лунда, который сказал: “Конечно, похоже, что” сообщество “думает, что изменение языка важнее, чем его использование…” [5]. Патрик уточняет:
То, что я имею в виду,-это своего рода очень краткий Strunk-&-White-like “Elements of Style” для Python, который предлагает фундаментальные идиоматические рекомендации для работы в духе языка. Дистилляция Python Zen-это то, о чем я говорю-что-то, что нужно сделать и созерцать, когда децибелы “fix Python now” становятся немного чересчур.
Школа дзэн дает советы и рекомендации. Вы понимаете это своими собственными упражнениями и в компании кого-то опытного в этом ремесле
она снимает акцент с простого знания сутр и доктрин и способствует прямому пониманию через духовную практику и взаимодействие с совершенным учителем или Мастером.]
Дзэн был просьбой помочь людям Python достичь состояния ума Python, чтобы ваш код хорошо резонировал со структурой, стоящей за ним, передавая в процессе связанную красоту, элегантность и утонченность. Эти руководящие принципы, если они будут хорошо пропитаны, сделают ваш кодекс почитаемым в кругу истинных монахов.
Но, как ни странно, Тим рассказывает [19]:
Если бы я хотел что-то изменить, я бы отбросил ссылку на “Дзен”. Это не было частью оригинала и было добавлено кем-то другим.
Другими словами, название не от автора [23]
Strunk & White – это имя двух людей, а именно Уильяма Странка и Элвина Брукса Уайта. Странк писал The Elements of Style , признанная The Times одной из самых влиятельных книг с 1923 года [3]. Уайт, который был учеником и редактором Странка после смерти профессора, описывает книгу так::
сорок три страницы суммирования аргументов за чистоту, точность и краткость в использовании английского языка [4]
Эффект книги описан ниже, он был поражен:
он опускал так много ненужных слов, и опускал их так решительно, с таким рвением и явным наслаждением, что часто казалось, будто он сам себя обманул — человек, которому больше нечего сказать, но у которого еще есть время, радиопророк, опередивший часы. Уилл Странк вышел из этого затруднительного положения простым трюком: он произнес каждую фразу по три раза
Одним из эффектов применения Дзэн тогда также были бы более легкие файлы кода.
Мастер Тим услышал просьбу, одобрил требование и ответил соответственно [6]
Очевидно, это работа только для Гвидо-хотя я сомневаюсь, что он возьмет ее на себя (фу-у-у, я бы тоже хотел!). Вот набросок, с которого он начал бы, хотя <подмигивание>:
Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!
20-е место осталось за Гвидо:
Вот вам: 20 питонских тезисов Fec^H^H^H на носу, считая тот, который я оставляю в Кито, чтобы заполнить.
Почтенный Тим делится тем, как именно появились эти строки [15]:
Это был одноразовый пост из списка питонов. Но, как и все великие триумфы литературы, она была написана во время рекламных пауз, во время просмотра профессионального рестлинга по телевизору и жевания бутерброда с ветчиной. Все верно!
И все же автор категоричен: она полна и более чем удовлетворяет требованию [6]:
Если ответ на любой вопрос дизайна Python не очевиден после их прочтения-что ж, я просто сдаюсь .
Вышесказанное также раскрывает цель Дзэн: решать вопросы дизайна. И это не простое дело. Гвидо говорит [18]:
Во многих отношениях философия дизайна, которую я использовал при создании Python, вероятно, является одной из главных причин его окончательного успеха.
Дзэн дает только контуры, в отличие от Странка и Уайта, которые дают объяснения и примеры в дополнение. Отсюда и необходимость в комментариях. Они помогают не посвященным, не заменяя собой компанию светлых умов.
Во времена колеблющихся и управляемых стандартов ссылка в фактическом документе PEP8 на Странка и Уайта в употреблении английского языка вызвала горькую, уродливую и грязную нить [7]. Это заставило некоторых из лучших людей сообщества отказаться от следования python-list [8], случайного напоминания о том, что быть слишком открытым без ограничений вредно.
Дзэн стал важной частью языка программирования Python. Если вы не знаете дзэн, вы не найдете нужной струны для общения с общиной. Раймонд Хеттингер советует:
Прежде чем создавать новые трекеры, пожалуйста, найдите время, чтобы узнать об истории Python, его использовании и культурных нормах. В частности, прочтите Дзен Питона, подумайте, что подразумевается под утиным набором текста, что подразумевается под “согласным языком взрослых”, что подразумевается под чрезмерной спецификацией и т. Д. В этом отношении Python сильно отличается от Java. [13]
В этом есть и практический аспект. Он популярен, потому что работает [14]. Это золотой руководящий принцип практически во всем, что касается Python.
Наконец, являются ли правила точек Дзен? Какие они на самом деле. Многие люди принимают дзэн за правила. “Самый самоуверенный линтер когда-либо” в свое время фактически включил Дзэн в поддержку своих взглядов [9]. Именно такие ситуации побудили меня написать: Дзен Питона-Это Шутка, И вот Почему [10]. Это было достаточно хорошо для Майкла Кеннеди и Брайана Оккена, чтобы назвать его “обязательным чтением” на байтах Python [11].
По словам Ника Коглана, Дзен дает вам идею, а не все [12]:
Эта проблема отражается в том факте, что Дзен Python намеренно самопротиворечив, поскольку он формулирует конкурирующие принципы проектирования, которые следует принимать во внимание, а не способен обеспечить железные правила, которые избегают необходимости человеческого суждения при определении того, какие из этих принципов проектирования наиболее заметны в любой конкретной ситуации.
Самопротиворечивость также случайно является одним из критикуемых аспектов Странка и Уайта [17]. Дзэн также выходит за рамки кодирования, такого как формирование мысленного паттерна признаков [12]:
То, над чем мы работаем как разработчики ядра и начинающие разработчики ядра, – это хорошая дизайнерская интуиция, которая согласуется с дзеном Python. Это не означает, что мы все будем в состоянии в совершенстве сформулировать эту интуицию в каждом конкретном случае, и даже когда мы сможем, эти объяснения сами по себе, как правило, будут подкреплены интуицией, а не строгими научными исследованиями.
Если бы я сам когда-нибудь добавил 20-ю, это было бы: “Используй свое суждение”, Но Ник проиллюстрировал это лучше.
Что касается знаменитой команды import this , то это был выбор Барри Варшавы. Он прокрался туда тайком. this.py в 2001 году наряду с обфускацией ROT13 [16]. Он также упомянул, что это было время, “когда у сообщества питонов было чувство юмора”.
Теперь пришло время увидеть, что на самом деле означает дзэн. Но прежде мы должны знать, что все, что означают слова и понятия в дзэн, не обязательно применимо в других местах [20].
Красивое лучше, чем уродливое.
Красивое и уродливое в этом контексте не имеет ничего общего с человеческой внешностью. Это в том же общем смысле, что и в других технических областях: есть красивая и уродливая физика, красивая и уродливая математика, красивый и уродливый компьютерный код [19]. Красота в дизайне очень похожа на красоту во флоре. Ибо оно относится к общему чувству последовательности, чистоты и выделенности. Она абстрактна и не имеет ничего общего с людьми [20]. Эту строчку можно заменить на “Элегантный лучше, чем неэлегантный”, чтобы лучше понять ее [21]. Линия “красота” – это один из многочисленных контрастов, и о ней следует судить в этом контексте, а не изолированно [22]. В глубине души дизайн Python возник из чувства красоты Гвидо [23]
Явное лучше, чем неявное.
Дзен Python указывает, что “явное лучше, чем неявное” по определенной причине: двусмысленность и неявное знание, которое нелегко передать коду, легко ошибиться и привести к ошибкам. Заставляя разработчиков явно разделять свои двоичные данные и текстовые данные, это приводит к улучшению кода, который имеет меньше шансов иметь определенный класс ошибок.
Бретт Кэннон [25]
Было интересно посмотреть, как ppl интерпретирует “явное лучше, чем неявное”, чтобы сказать, что указание “объекта” хорошо. Для меня синтаксический отказ от базового класса является явным, а не подробным и более визуально идентифицируемым
Бретт Кэннон [26]
Неявные каталоги пакетов идут вразрез с Дзен Python
Сначала уберите этого с дороги. Как я вижу, неявные каталоги пакетов нарушают по крайней мере 4 принципа проектирования в Zen:
- Явное лучше, чем неявное (я называю их неявными пакетами каталогами-это преднамеренная риторическая уловка, чтобы подчеркнуть этот момент, хотя это также точное название)
- Если реализацию трудно объяснить, это плохая идея (см. Раздел о проблемах обратной совместимости)
- Подсчет читабельности (см. раздел о введении неоднозначности в макеты файловой системы )
- Ошибки никогда не должны проходить бесшумно (см. раздел о неявном относительном импорте из main)
Ник Коглан [24]:
Простое лучше, чем сложное.
В настоящее время, когда я преподаю наборы, я получаю удовольствие от почти нулевой кривой обучения и отсутствия особых случаев. Набор кода становится ярким примером “считываемости” и “простой лучше, чем сложный.” Что еще более важно, я думаю, что есть ценность в простоте API для списков, наборов и диктовок, наших основных инструментов. Четыре набора азбуки в настоящее время отражают эту простоту, и было бы печально, если бы это начало теряться, чтобы сохранить одну строку здесь или там.
Раймонд Хеттингер [39]
Сложное лучше, чем сложное.
oxfordlearnersdictionaries.com дает как сложное, так и сложное как синонимы со значением: “сделано из множества различных вещей или частей, которые связаны; трудно понять”
dictionary.cambridge.org дает сложный как: “имеющий много частей, связанных способами, которые трудно понять” и сложный как: “запутанный или трудный для понимания”
macmillandictionary.com определяет сложное как: “что-то сложное имеет много деталей или мелких частей, которые затрудняют его понимание или работу” и сложное как: “трудно сделать, иметь дело или понять, особенно из-за вовлечения множества различных процессов или аспектов” и 2. “состоит из множества различных, но связанных частей”
merriam-webster.com дает сложное как: целое, состоящее из сложных или взаимосвязанных частей и состоящее из двух или более частей, сложное как: состоящее из частей, запутанно объединенных и трудных для анализа, понимания или объяснения
Мы можем перевести эту строку как означающую:
Решение, состоящее из различных взаимосвязанных частей, лучше, чем решение, которое трудно проанализировать, понять или объяснить
или
Сложное решение лучше, чем более сложное
или
Решение, состоящее из различных взаимосвязанных частей, лучше, чем решение, состоящее из множества частей, но трудно поддающееся анализу, пониманию или объяснению
Плоский лучше, чем вложенный.
Вложенность конструкций, таких как условные выражения, функции, классы или модули, одна внутри другой, слишком часто вызывает неодобрение. Пример x.y.z.q.w.w приведен как автор lib, вложивший слишком много модулей один в другой, учитывая утомительный опыт использования
Разреженный лучше, чем плотный.
Когда я направил “разреженный лучше, чем плотный” в качестве одного из фундаментальных принципов дизайна Гвидо, я был так же озадачен, как и все остальные. Действительно, моей первой мыслью было: “Что, черт возьми, это должно означать?!”. Но, как профессиональный ченнелер, я был обязан передавать его по мере того, как он раскрывался, не добавляя и не убирая ни слова.
За прошедшие годы я понял, что оно имеет много значений, некоторые из которых я объяснил вчера. Я узнаю из других вдумчивых постов (таких как ваш), что мне еще предстоит пройти долгий путь в разработке его полной глубины. Или в осознании его полной поверхностности, в зависимости от того, как вы его рассматриваете.
<< Или, может быть, его внимание просто в другом месте… но мне хотелось бы думать, что это дзенский коан.
О нет. Займы гораздо более продвинуты, по своей природе они похожи на использование палки для разжигания огня, который поглощает палку в ее стремлении осветить свою собственную природу. Ченнелинговые 20 питонских тезисов (их первоначальное название – “Дзен Питона” – было приколото кем-то другим, кто, как я подозреваю, на самом деле не был мастером Дзен) больше связаны с использованием палок для создания сильной платформы, как если бы палки были реальными и сильные платформы были достойны строительства. Нужен более сильный ченнелер, чем я, чтобы отмахнуться от этого как от иллюзии. Конец Пифонического Просветления-это удовольствие от достижения тонкого кода; этого недостаточно, чтобы получить Нирвану, вероятно, потому, что она все еще полна палочек <подмигивание>.
<<В отличие от большинства других людей в этой теме, я всегда думал о sparse v. dense как о синтаксической/семантической проблеме.>>
Это определенно часть его. Открытость внешнего вида Python, повсеместное использование диктовок и тщательно подобранная горстка контрольных структур были первыми вещами, о которых я подумал.
<<… Я, вероятно, читаю в этом маленьком заявлении больше, чем есть.
Я не верю, что это возможно. Постарайся усерднее <подмигнуть>.
Тим Питерс [40]
Читабельность имеет значение.
Опять это слово “читабельность”. Иногда я жалею, что Дзен Питона не использовал его, потому что все, кажется, думают, что “читаемый” означает “код, который мне нравится”.
Крис Анжелико [34]
Девиз Python-ясность. Язык пытается быть таким же читаемым, как и английский. Гвидо говорит [18]:
Я хотел бы особо отметить одно правило читабельности: знаки препинания должны использоваться консервативно, в соответствии с их общим использованием в письменном английском или алгебре средней школы.
Особые случаи не настолько особенные, чтобы нарушать правила.
Хотя практичность превосходит чистоту.
если вы переходите от 8-битных строк к юникоду с помощью неявного преобразования, текущий дизайн может дать вам:
"UnicodeError: UTF-8 decoding error: unexpected code byte"
если вы перейдете от юникода к 8-битным строкам, вы никогда не получите ошибку.
однако результат не всегда является строкой-если строка unicode содержит какие-либо символы больше 127, результатом является двоичный буфер, содержащий закодированные данные. вы не можете использовать строковые методы на нем, вы не можете использовать регулярные выражения на нем. индексирование и нарезка не будут работать.
unlike earlier versions of Python, and unlike unicode-aware versions of Tcl and Perl, the fundamental assumption that a string is a sequence of characters no longer holds. =20
в моем предложении переход от 8-битных строк к юникоду всегда работает. символ-это символ, независимо от того, какой тип строки вы используете.
однако переход от юникода к 8-битной строке может привести к ошибке переполнения, скажем:
"OverflowError: unicode character too large to fit in a byte"
здесь важно то, что если вы не получаете исключения, то результатом всегда будет строка. строковые методы всегда работают. и т.д.
[8. Особые случаи не настолько особенные, чтобы нарушать правила.]
Фредрик Лундх [42]
Во-первых, я думаю, что дело PyCharm достаточно убедительно само по себе. После того, как я отправил его, я понял, что есть связанный класс инструментов, которые меня интересуют: PyFlakes, PyLint и тому подобное. Я уверен, что статические анализаторы корректности хотели бы иметь возможность автоматически определять “это недопустимое количество параметров для этой функции” для встроенных модулей-особенно для сторонних встроенных модулей! Тот факт, что нам не нужно было бы использовать особый случай pydoc, говорит о том, что это превосходный подход. (“Особые случаи не настолько особенные, чтобы нарушать правила.”)
Ларри Гастингс [41]
Ошибки никогда не должны проходить бесшумно.
Если только явно не замолчать.
Таким образом, в Python 2.3 мы отказались от моего доморощенного алгоритма 2.2 MRO в пользу академически проверенного алгоритма C3. Одним из результатов этого является то, что Python теперь будет отвергать любую иерархию наследования, которая имеет несогласованный порядок базовых классов. Например, в предыдущем примере существует конфликт порядка между классами X и Y. Для класса X существует правило, которое гласит, что класс A должен быть проверен перед классом B. Однако для класса Y правило гласит, что класс B должен быть проверен перед классом A. В изоляции это расхождение прекрасно, но если X и Y когда-либо объединяются вместе в одной иерархии наследования для другого класса (например, в определении класса Z), этот класс будет отклонен алгоритмом C3. Это, конечно, соответствует дзенскому правилу Python “ошибки никогда не должны проходить бесшумно”.
Гвидо [33]
Это, конечно, обратно несовместимое изменение семантики ведения журнала: вместо того, чтобы говорить, что ведение журнала будет молчать, если явно не попросят произвести вывод, мы говорим, что ведение журнала всегда будет производить вывод для предупреждений и ошибок (или, возможно, просто ошибок), если явно не заставят замолчать. Это, конечно, соответствует Дзен Python; нынешнее поведение, которое не так выровнено, основано на идее, что ведение журнала не должно влиять на поведение программы, если этого не хочет разработчик программы (в отличие от разработчика библиотеки).
Это также означало бы изменение документации о NullHandler, чтобы сказать: “Если у вас есть сообщения, которые должны выходить, когда вы не можете вызвать исключение, то не добавляйте NullHandler в свои регистраторы верхнего уровня.”
Винай Саджип [28]
Возможно, вы предпочтете получить исключение для “отсутствующих ключей”, которое поможет предупредить вас об ошибке в вашей программе, в тех случаях, когда вы знаете, что все ks в somekeys определенно должны быть ключами в somedict. Помните: “ошибки никогда не должны проходить бесшумно. Если только явно не замолчать”, цитируя Дзен Питона-Поваренную книгу Питона
Перед лицом двусмысленности откажитесь от искушения угадать.
Что ж, дзен Питона гласит: “Перед лицом двусмысленности откажитесь от соблазна угадать”. Таким образом, это политика, которой следует встроенный диктант – он не пытается угадать, когда делать копию или использовать ли семантику, основанную на идентичности, перед лицом изменчивости. Вместо этого он вызывает исключение во время ввода ключа, прося программиста уточнить свои намерения.
Ник Коглан [37]
По вопросу {a.b.c}: как и нескольким корреспондентам, мне не очень нравится двусмысленность ссылок атрибутов и ключей, хотя она кажется достаточно полезной на практике в веб-фреймворках, которые я использовал. Это, кажется, нарушает Дзен Питона: “Перед лицом двусмысленности откажитесь от искушения угадать.”
К сожалению, я довольно прохладно отношусь к предложению поддержать {a[b].c}, поскольку b-это не ссылка на переменную, а литеральная строка “b”. Он также относительно громоздок для разбора. Я хотел бы предложить {a+b.c} для этого случая, но это так произвольно…
Гвидо [31]
Теперь вы, вероятно, можете себе представить, почему Python отказывается угадывать среди сотен возможных кодировок. Это решающий выбор дизайна, основанный на одном из принципов Дзен Питона: “Перед лицом двусмысленности не поддавайтесь искушению угадать”.
Должен быть один-и желательно только один-очевидный способ сделать это.
Но помните ТУУТДИ из Дзен Питона.
Гвидо [32]
Дзен Питона говорит, что “должен быть один-и предпочтительно только один-очевидный способ сделать это”. Наличие литералов в языке, которые могли бы представлять либо текстовые данные, либо двоичные данные, было проблемой.
Бретт Кэннон [25]
Когда Python развивается, неизбежно появляются новые способы. DeprecationWarning испускаются, чтобы предложить использовать новый способ, но многие разработчики игнорируют эти предупреждения, которые по умолчанию молчат.
Виктор Стиннер [35]
Форматирование строк – это одна из тех вещей, которые бросают вызов дзену Python, что должен быть только один очевидный способ делать вещи.
Мариетта Виджая [36]
Следует отметить, что тире здесь не играет никакой роли, так как это способ акцентирования Тима. И надо отметить, что Бретт пропустил это в своем блоге. Возможно, он писал по памяти.
Хотя поначалу это может показаться неочевидным, если только вы не голландец.
В контексте “голландец” означает человека из Нидерландов или человека, проникнутого голландской культурой (прошу прощения за это злоупотребление словом). Я бы сказал по-французски, но каждый француз, которого я спрашивал: “как вы делаете неглубокую копию списка?”, не смог ответить: alist [:] так что я думаю, что это не очевидно для них. Однако это должно быть очевидно для голландцев, поскольку это очевидно для Гвидо ван Россума (создателя Python, который является голландцем), и упорный слух утверждает, что все, кто публикует сообщения в comp.lang.python, на самом деле тоже голландцы. Французы, которых я спрашивал о копировании списка, не были пользователями Python, что является еще большим доказательством (как будто ему нужно было больше).
Или, другими словами, “очевидное” – это отчасти научное, культурное суждение. На самом деле нет ничего универсально очевидного в любом компьютерном языке, несмотря на заблуждающихся сторонников. Тем не менее, большая часть Python очевидна для голландцев. Другим иногда приходится немного поработать над изучением одного очевидного способа в Python, точно так же, как им приходится немного поработать над тем, чтобы научиться ценить тюльпаны и олицетворения Вуди Дятла.
Тим Питерс [38]
Сейчас лучше, чем никогда.
Хотя никогда не бывает часто лучше, чем сейчас.
Есть также случаи, когда мы решим: “Кажется вероятным, что это может быть хорошей идеей, поэтому давайте попробуем это и посмотрим, что произойдет на практике, а не продолжим спекулировать” – только когда-либо делать вещи, в которых вы уже на 100% уверены, что это хорошая идея, – это рецепт застоя и упадка (отсюда строка “Сейчас лучше, чем никогда” в Дзен).
Ник Коглан [27]
Если реализацию трудно объяснить, это плохая идея.
Если реализация проста в объяснении, это может быть хорошей идеей.
Да, это то, что все предлагают, чтобы сохранить семантику языка неизменной. Но я утверждаю, что более простое решение-это сказать: к черту эту семантику, давайте изменим ее, чтобы сделать реализацию проще. Это из Дзен Питона: “Если реализация проста в объяснении, это может быть хорошей идеей.” Я думаю, что мало кто может всерьез предложить изменить семантику Python, вот почему я предлагаю это.
Гвидо [29]
Принятие peeps: Немного больше мотивации для моего выбора: перечитывание PEP 549 напомнило мне о том, как его реализация удивительно тонка (призывая Армина Риго; для получения более подробной информации читайте https://www.python.org/dev/peps/pep-0549/#implementation). Напротив, реализация PEP 562 намного проще. Имея в виду Дзен Питона, это дает намек на то, что это лучшая идея, и, возможно, даже хорошая идея.
Гвидо [30]
Пространства имен-это одна из самых замечательных идей-давайте сделаем их побольше!
Пространства имен (а также глобальные и локальные области) являются ключевыми для предотвращения конфликтов имен в одном модуле или области с именами в другом. Но также помните, что плоские лучше, чем вложенные: как бы велики они ни были, пространства имен должны создаваться только для предотвращения конфликтов имен, а не для добавления ненужной категоризации.
Эл Свейгарт [43]
Займы принесли миру программирования великое наследие. Это интересное зрелище можно наблюдать от разработчиков Go до JavaScript, анализирующих свои собственные земли в свете дзен.
Ваши предложения принимаются по адресу: arj [.] python [@] gmail [.] com
[1] https://mail.python.org/pipermail/python-list/1999-June/014096.html [2] https://en.wikipedia.org/wiki/Zen со ссылками на Почески и Ямпольского [3] Все 100 научно-популярных книг. Time, Inc. Извлечено 2014-05-14. [4] http://www.jlakes.org/ch/web/The-elements-of-style.pdf [5] https://mail.python.org/pipermail/python-list/1999-June/017368.html [6] https://mail.python.org/pipermail/python-list/1999-June/001951.html [7] https://mail.python.org/archives/list/python-ideas@python.org/thread/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/[8] https://www.mail-archive.com/python-dev@python.org/msg109166.html [9] https://github.com/wemake-services/wemake-python-styleguide/tree/fd7b6d9d14d73cab3d7f3ac4c910e4c75b093c4c [10] https://dev.to/abdurrahmaanj/the-zen-of-python-is-a-joke-and-here-is-why-you-should-not-take-it-too-seriously-508d [11] https://pythonbytes.fm/episodes/show/170/visualize-this-visualizing-python-s-visualization-ecosystem [12] https://mail.python.org/archives/list/python-dev@python.org/