Дзен питона: Дзен питона на русском / Тяпк

Дзен питона на русском / Тяпк

Разработчики языка Python придерживаются определённой философии программирования, называемой «The Zen of Python» («Дзен Питона», или «Дзен Пайтона»). Её текст выдаётся интерпретатором Python по команде import this (работает один раз за сессию).

В целом она подходит к программированию на любом языке.

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

Автор этой философии – Тим Петерс. Оригинал на английском:

λ python
Python 3.6.2 (v3.6.2:5fd33b5, Jul  8 2017, 04:14:34) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters
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!

P.S. Чтобы 2 раза не вставать: 20 вопросов и ответов из интервью на позицию Python-разработчика

Отсылка к нидерландскому программисту, создавшему язык Python, Гвидо ван Россуму (нидерл. Guido van Rossum).

Первоначальная настройка Sublime Text

Установка пакетного менеджера (Package Control), установка пакетов на примере Emmet, несколько полезных пакетов Sublime Text 3.

Улучшение контрастности темы Material Theme редактора Visual Studio Code

Для Visual Studio Code есть несколько тем в стиле материального дизайна, и все они с недостатками: либо некорретная подстветка синтаксиса, либо проблемы с контрастностью.

Про дистанционное обучение

Выбрав IT профессию, вы выбираете путь бесконечного обучения. Список отличных ресурсов для онлайн обучения.

Cmder — терминал для Windows

Portable console emulator for Windows

mocha и node.js

mocha – js фреймворк для тестирования

Python to exe

Про конвертер .py в .exe с использованием простого графического интерфейса, созданного с использованием Eel и PyInstaller в Python

философии программирования PEP20 (на русском)

upd:

16.10.2021

Александр Попов

20.2K

2

Содержание:развернуть

Python является одним из самых простых и при этом мощных языков программирования. Он широко востребован сегодня, такие компании как IBM, Google, Facebook и многие другие создают свои продукты именно на Python. Также стоит отметить, что “Питон” — это язык программирования с большим потенциалом на будущее.

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

Одним из важных вкладов в развитие Python стал свод правил Дзен Питон или как его еще называют PEP20 (python enhanced proposal — заявки на улучшение языка Питон) от Тима Петерсона.

История создания PEP20

В 1999 году Тим Петерс предложил свой свод правил по улучшению языка Питон. Дзен Python представлял собой 20 пунктов, последний из которых не был заполнен. Автор предложил написать последнее правило создателю “Питона” Гвидо Ван Россуму. Стоит отметить, что и по сей день последнее правило Дзен-философии от Тима Петерса пустое. Некоторые полагают, что таким образом автор пытался донести до нас, что правила правилами, но могут быть и исключительные ситуации, когда нужно писать код исходя из сложившихся условий, при этом игнорируя установленные нормы.

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

Версии PEP

Кроме Тима Петерсона множество других заинтересованный в развитии Python людей подавали заявки на улучшение языка Питон. Каждое такое предложение получает свой номер. На сегодняшний день насчитывается порядка 8 000 таких заявок. Стоит понимать, что только часть из них были приняты. Остальные были либо оставлены на рассмотрение, либо вовсе отклонены.

Но те PEP, которые были приняты, в том числе и PEP под номером 20 от Тима Петерса, внесли свой вклад в развитие Питона.

PEP 20 в консоли

Найти Zen of Python можно на официальном сайте по языку программирования Python. Также ознакомиться с этой информацией можно в консольном приложении Python. Достаточно ввести всего одну команду import this и на экране высветиться свод из 19 правил на английском языке. Выглядит это следующим образом:

Zen of Python на русском языке

PEP20, а если быть точнее, то 19 правил по улучшению языка Питон от Тима Петерса, выглядят следующим образом на русском языке:

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

Советы по улучшению читабельности кода на Python

Благодаря философии Дзен на сегодняшний день код программ на Питоне один из самых читабельных и простых. Существует свод правил, придерживаясь которым, можно написать красивый код. Итак, нужно знать следующее:

• Наличие отступов в четыре символа делает код зрительно структурированным. Не стоит смешивать пробелы с табуляцией. При компиляции можно получить предупреждения от системы.
• Длина одной строки не должна превышать восьмидесяти символов, такой код не выглядит громоздким. Еще одно достоинство коротких строк – это возможность располагать на экране монитора сразу несколько окон с кодом.
• В код для разделения функций или каких-то больших логических блоков можно добавлять пустые строки.
• Наличие толковых комментариев облегчает последующее использование кода.

Еще больше полезных советов с примерами можно найти здесь. Следуя этим правилам можно получить хорошо читабельный код на Python. Но, чтобы облегчить задачу, можно воспользоваться какой-нибудь современной средой разработки. Так, например, выбрав PyCharm, при нажатии клавиши “Tab” автоматически проставляется нужные четыре пробела.

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

Дзен Python: руководство по принципам проектирования Python | by Vishal Sharma

Пишем чистый и красивый код!

Пифонист однажды написал 20 афоризмов о том, как можно писать красивый и чистый код с помощью Python. Эти афоризмы, ставшие известными как «Дзен Python», взорвали разработчиков Python. Тим Питерс написал эти BDFL (Benevolent Dictator For Life, прозвище создателя Python Гвидо ван Россум) 20 руководящих принципов для разработки Python, но последний афоризм был оставлен для заполнения ван Россумом.0005

На сегодняшний день существует 19 афоризмов, поскольку Россум сказала, что последний афоризм — это «какая-то странная шутка Тима Питерса». Но что означают эти афоризмы? Давайте взломаем это!

Дзен Питона

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

Вы можете открыть «пасхальное яйцо» в своей среде Python IDE, набрав:

import this

Красивое лучше, чем уродливое работа, чтобы сделать. Python известен своей удобочитаемостью и простотой. Так зачем вмешиваться? Написание чистого и читаемого кода — это искусство, которое ценят другие программисты и позволяют им понять каждый бит.

 def collatz(num): 
 if num%2 == 0: 
 return num//2 
 else: 
 return 3 * num + 1 
 number = input("Введите число:") 
 while number != 1: 
 number = collatz(int(number)) 
 print(number) 
 

В приведенном выше коде нет необходимости добавлять «else». В данный момент это кажется ненужным. В противном случае, чтобы сделать его лучше и чище, вы можете сделать что-то вроде:

 def collatz(num): 
 if num%2 == 0: 
 return num//2 
 return 3 * num + 1 
 

Явное лучше неявного

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

Простое лучше сложного

Зачем создавать сложный код, если можно создать более простой.

 def recursion_reverse(s): 
 if(len(s)==1): 
 return s 
 else: 
 return recursion_reverse(s[1:]) + s[0] 
 original_string = "ABC" 
 print("Reversed String : ", recursion_reverse(original_string)) 
 

Вы можете сделать это всего за две строки кода тоже.

 my_string = «ABCD» 
 reversed_string = my_string[::-1] 

Сложное лучше сложного

Приведенный выше афоризм утверждает, что простое лучше сложного. И теперь этот говорит: «Сложное лучше, чем сложное». Это становится запутанным! Для решения сложной проблемы может потребоваться сложная техника, но она не должна быть сложной.

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

Flat лучше, чем вложенный

Программисты любят создавать подмодули для каждой функциональности. Скажем, я создаю модуль с именем «спам» и добавляю подмодуль «foo», а в нем я добавляю «баз».

Теперь доступ к другому подпакету из baz будет выглядеть так:

 from spam.foo.baz импортирует яйца 

Вложенность и иерархия добавляют не организации, а бюрократии!

Разреженный лучше, чем плотный

Иногда мы стремимся сделать все в одной строке кода. Вы можете получить правильный вывод. Но как насчет читабельности? Может ли кто-нибудь понять это, не заглядывая в него долго?

 print('\n'.join("%i bytes = %i битов, которые имеют %i возможных значений." % (j, j * 8, 256 ** j - 1) для j в 
 (1 << я для я в диапазоне (8)))) 

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

Читабельность подсчитывается

Вы заходите в StackOverflow каждый раз, когда застреваете в своем коде? Итак, на какой код вы смотрите? Читаемый один или сложный кусок!

Говорят, что код больше читается, чем пишется. Так что, пожалуйста, ради читателей начните писать код, чтобы он был читабелен, как его любят наши коллеги-программисты.

Особые случаи не настолько особенные, чтобы нарушать правила

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

Хотя практичность превосходит чистоту

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

Ошибки никогда не должны проходить молча

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

Вот почему использование оператора «try-except» становится важным в коде. Везде, где вы думаете, что может произойти что-то подозрительное, вы должны добавить эту комбинацию и узнать об этих скрытых ошибках.

Если явно не заглушить

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

Перед лицом двусмысленности откажитесь от искушения угадать

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

Должен быть один — и желательно только один — очевидный способ сделать это

В программировании на Perl есть поговорка: «Есть больше одного способа сделать это!» Использование трех-четырех кодов для выполнения одного и того же действия похоже на палку о двух концах. Мало того, что на его написание уходит время, так еще и каждый товарищ должен уметь читать ваши 3–4 метода без каких-либо проблем. Гибкость в этой практике не стоит праздновать.

Хотя поначалу это может быть неочевидно, если вы не голландец

Ссылаясь на Гвидо ван Россума, создателя Python, этот афоризм говорит о том, что правило языка будет нелегко выучить или вспомнить, если только вы не станете создателем кода. Шутка, относящаяся к BDFL!

Лучше сейчас, чем никогда

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

Хотя никогда лучше, чем *прямо* сейчас

Лучше дождаться завершения программы, чем завершить ее раньше и получить неправильные результаты. Этот афоризм и приведенный выше «Лучше сейчас, чем никогда» похожи друг на друга и в то же время противоречат друг другу.

Если реализацию трудно объяснить, это плохая идея

Если вы объясняете кому-то свой код, а объяснить его знакомым или коллегам становится сложно, значит, с вашим кодом что-то не так . Это точно не просто и сложно!

Если реализацию легко объяснить, это может быть хорошей идеей

Прямо противоположно приведенному выше афоризму, этот просто говорит, что простой, читаемый код легко объяснить. И, если вы в состоянии сделать это, вы на правильном пути.

Пространства имен — это отличная идея — давайте сделаем больше таких!

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

 a = 2 
 print('id(a) =', id(a)) 
 a = a+1 
 print('id(a) =', id(a)) 
 
 print('id( 3) =', id(3)) 
 

Выведено:

 id(a) = 9302208 
 id(a) = 9302240 
 id(3) = 9302240 

То, как Python организует переменные под капотом, просто невероятный. Вот почему пространства имен — это круто!

Заключение

Python великолепен! Вот почему миллионы разработчиков используют его, пишут в нем код, анализируют с его помощью данные и строят с его помощью модели. Руководящие принципы, сделанные для него, только мотивируют программистов писать простой, читаемый и чистый код. В следующий раз, когда вы сядете за программирование, попробуйте следовать этим рекомендациям.

 >>> import this
Дзен Python, Тим Питерс

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