Zen of Python

Last updated
The Zen of Python output in a terminal Zen Of Python.png
The Zen of Python output in a terminal

The Zen of Python is a collection of 19 "guiding principles" for writing computer programs that influence the design of the Python programming language. [1] Python code that aligns with these principles is often referred to as "Pythonic". [2]

Contents

Software engineer Tim Peters wrote this set of principles and posted it on the Python mailing list in 1999. [3] Peters' list left open a 20th principle "for Guido to fill in", referring to Guido van Rossum, the original author of the Python language. The vacancy for a 20th principle has not been filled.

Peters' Zen of Python was included as entry number 20 in the language's official Python Enhancement Proposals and was released into the public domain. [4] It is also included as an Easter egg in the Python interpreter, where it can be displayed by entering importthis. [1] [4] [a]

In May 2020, Barry Warsaw (developer of GNU Mailman) used it as the lyrics to a song. [5] [6]

Principles

The Zen of Python illustrated The Zen of Python illustrated.png
The Zen of Python illustrated

The principles are listed as follows: [b]

  • 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. [c]
  • 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. [d]
  • 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!

Being Pythonic

One of the principles, "There should be one-- and preferably only one --obvious way to do it", can be referenced as the "Pythonic" way. [8] The official definition of "Pythonic" is: [2]

An idea or piece of code which closely follows the most common idioms of the Python language, rather than implementing code using concepts common to other languages. For example, a common idiom in Python is to loop over all elements of an iterable using a for statement. Many other languages don’t have this type of construct, so people unfamiliar with Python sometimes use a numerical counter instead:

foriinrange(len(food)):print(food[i])

As opposed to the cleaner, Pythonic method:

forpieceinfood:print(piece)

Code that is difficult to understand or reads like a rough transcription from another programming language is called unpythonic. [9]

In practice

Since the release of the Zen of Python, there has been research done on its effectiveness and actual use among developers. Despite the difference in interpretation between beginners and experienced Python programmers, interviews among 13 Python programmers of varying skill show that the Zen of Python "positively influences the way developers write and talk about code". [8] Researchers extended this case study to explore the use of Python idioms on GitHub repositories, and found that the usage of "Pythonic idioms" [e] increased over time. [10] Writing Python code that aligns with the Zen of Python may save memory and run time of Python programs. [11] The desire to write in Pythonic code has led to refactoring tools to help programmers achieve this goal. [12] [13]

See also

Notes

  1. The source code for the Zen of Python can be found on Github.
  2. Wikipedia links below are added for further reference and understanding, and were not explicitly linked in the Zen of Python
  3. The formatting of the dashes in this line and the final is purposely inconsistent, in reference to the varying formatting conventions. [7]
  4. In the interpreter easter egg, this is written as "Although never is often better than *right* now." This follows a longstanding convention of plain-text communication — in which common formatting features are often impossible — where emphasis is represented with asterisks.
  5. A list of their Pythonic idioms can be found here https://slimshadyiam.github.io/ZenYourPython/

Related Research Articles

In computer programming and software design, code refactoring is the process of restructuring existing source code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

Unit testing, a.k.a. component or module testing, is a form of software testing by which isolated source code is tested to validate expected behavior.

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

<span class="mw-page-title-main">PL/C</span> Programming language developed at Cornell University

PL/C is an instructional dialect of the programming language PL/I, developed at the Department of Computer Science of Cornell University in the early 1970s in an effort headed by Professor Richard W. Conway and graduate student Thomas R. Wilcox. PL/C was developed with the specific goal of being used for teaching programming. The PL/C compiler, which implemented almost all of the large PL/I language, had the unusual capability of never failing to compile a program, through the use of extensive automatic correction of many syntax errors and by converting any remaining syntax errors to output statements. This was important because, at the time, students submitted their programs on IBM punch cards and might not get their output back for several hours. Over 250 other universities adopted PL/C; as one late-1970s textbook on PL/I noted, "PL/C ... the compiler for PL/I developed at Cornell University ... is widely used in teaching programming." Similarly, a mid-late-1970s survey of programming languages said that "PL/C is a widely used dialect of PL/I."

In computer science, an algorithm is called non-blocking if failure or suspension of any thread cannot cause failure or suspension of another thread; for some operations, these algorithms provide a useful alternative to traditional blocking implementations. A non-blocking algorithm is lock-free if there is guaranteed system-wide progress, and wait-free if there is also guaranteed per-thread progress. "Non-blocking" was used as a synonym for "lock-free" in the literature until the introduction of obstruction-freedom in 2003.

In computer software, a general-purpose programming language (GPL) is a programming language for building software in a wide variety of application domains. Conversely, a domain-specific programming language (DSL) is used within a specific area. For example, Python is a GPL, while SQL is a DSL for querying relational databases.

Jikes Research Virtual Machine is a mature virtual machine that runs programs written for the Java platform. Unlike most other Java virtual machines (JVMs), it is written in the programming language Java, in a style of implementation termed meta-circular. It is free and open source software released under an Eclipse Public License.

In software engineering, profiling is a form of dynamic program analysis that measures, for example, the space (memory) or time complexity of a program, the usage of particular instructions, or the frequency and duration of function calls. Most commonly, profiling information serves to aid program optimization, and more specifically, performance engineering.

In computer programming, a programming idiom, code idiom or simply idiom is a code fragment having a semantic role which recurs frequently across software projects. It often expresses a special feature of a recurring construct in one or more programming languages, frameworks or libraries. This definition is rooted in the linguistic definition of "idiom".

Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers.

In computer science, pointer analysis, or points-to analysis, is a static code analysis technique that establishes which pointers, or heap references, can point to which variables, or storage locations. It is often a component of more complex analyses such as escape analysis. A closely related technique is shape analysis.

Matthew Flatt is an American computer scientist and professor at the University of Utah School of Computing in Salt Lake City. He is also the leader of the core development team for the Racket programming language.

<span class="mw-page-title-main">Incremental computing</span> Software feature

Incremental computing, also known as incremental computation, is a software feature which, whenever a piece of data changes, attempts to save time by only recomputing those outputs which depend on the changed data. When incremental computing is successful, it can be significantly faster than computing new outputs naively. For example, a spreadsheet software package might use incremental computation in its recalculation features, to update only those cells containing formulas which depend on the changed cells.

Haskell is a general-purpose, statically-typed, purely functional programming language with type inference and lazy evaluation. Designed for teaching, research, and industrial applications, Haskell has pioneered several programming language features such as type classes, which enable type-safe operator overloading, and monadic input/output (IO). It is named after logician Haskell Curry. Haskell's main implementation is the Glasgow Haskell Compiler (GHC).

Gradual typing is a type system that lies inbetween static typing and in dynamic typing. Some variables and expressions may be given types and the correctness of the typing is checked at compile time and some expressions may be left untyped and eventual type errors are reported at runtime.

Example-centric programming is an approach to software development that helps the user to create software by locating and modifying small examples into a larger whole. That approach can be helped by tools that allow an integrated development environment (IDE) to show code examples or API documentation related to coding behaviors occurring in the IDE. “Borrow” tactics are often employed from online sources, by programmers leaving the IDE to troubleshoot. The purpose of example-centric programming is to reduce the time spent by developers searching online. Ideally, in example-centric programming, the user interface integrates with help module examples for assistance without programmers leaving the IDE. The idea for this type of “instant documentation” is to reduce programming interruptions. The usage of this feature is not limited to experts, as some novices reap the benefits of an integrated knowledge base, without resorting to frequent web searches or browsing.

<span class="mw-page-title-main">Sonic Pi</span> Live coding environment

Sonic Pi is a live coding environment based on Ruby, originally designed to support both computing and music lessons in schools, developed by Sam Aaron in the University of Cambridge Computer Laboratory in collaboration with Raspberry Pi Foundation.

Automatic bug-fixing is the automatic repair of software bugs without the intervention of a human programmer. It is also commonly referred to as automatic patch generation, automatic bug repair, or automatic program repair. The typical goal of such techniques is to automatically generate correct patches to eliminate bugs in software programs without causing software regression.

A sea of nodes is a graph representation of single-static assignment (SSA) representation of a program that combines data flow and control flow, and relaxes the control flow from a total order to a partial order, keeping only the orderings required by data flow. It is similar to a value dependency graph (VDG).

References

  1. 1 2 Reitz, Kenneth (2011–2019). "Code Style". The Hitchhiker’s Guide to Python. § Zen of Python. Retrieved March 26, 2019.
  2. 1 2 "Glossary". Python Documentation. Retrieved 2024-02-07.
  3. Peters, Tim (June 4, 1999). "The Python Way". Python Software Foundation . Retrieved March 26, 2019.
  4. 1 2 Peters, Tim (August 19, 2004). "PEP 20—The Zen of Python". Python Software Foundation . Retrieved March 26, 2019.
  5. Warsaw, Barry (10 May 2020). "The Zen of Python". We Fear Change. Archived from the original on 2020-06-03.
  6. Warsaw, Barry (23 May 2020). The Zen of Python. YouTube . The Zbwedicon. Archived from the original on 2021-12-11. Archived 2020-06-03 at the Wayback Machine
  7. "Issue 3364: An ortographical typo in Zen of Python text - Python tracker" . Retrieved 2021-02-10.
  8. 1 2 Alexandru, Carol V.; Merchante, José J.; Panichella, Sebastiano; Proksch, Sebastian; Gall, Harald C.; Robles, Gregorio (2018-10-24). "On the usage of pythonic idioms". Proceedings of the 2018 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (PDF). Onward! 2018. New York, NY, USA: Association for Computing Machinery. pp. 1–11. doi:10.1145/3276954.3276960. ISBN   978-1-4503-6031-9. OCLC   1362712424. S2CID   53057358. Archived from the original on 2018-10-03.
  9. "Code Style – The Hitchhiker's Guide to Python". docs.python-guide.org. Archived from the original on 27 January 2021. Retrieved 20 January 2021.
  10. Farooq, Aamir; Zaytsev, Vadim (2021-11-22). "There is more than one way to zen your Python". Proceedings of the 14th ACM SIGPLAN International Conference on Software Language Engineering. SLE 2021. New York, NY, USA: Association for Computing Machinery. pp. 68–82. doi:10.1145/3486608.3486909. ISBN   978-1-4503-9111-5.
  11. Leelaprute, Pattara; Chinthanet, Bodin; Wattanakriengkrai, Supatsara; Kula, Raula Gaikovina; Jaisri, Pongchai; Ishio, Takashi (2022-10-20). "Does coding in Pythonic zen peak performance?: Preliminary experiments of nine Pythonic idioms at scale". Proceedings of the 30th IEEE/ACM International Conference on Program Comprehension. ICPC '22. New York, NY, USA: Association for Computing Machinery. pp. 575–579. doi:10.1145/3524610.3527879. ISBN   978-1-4503-9298-3.
  12. Zhang, Zejun; Xing, Zhenchang; Xia, Xin; Xu, Xiwei; Zhu, Liming (2022-07-12), Making Python Code Idiomatic by Automatic Refactoring Non-Idiomatic Python Code with Pythonic Idioms, arXiv: 2207.05613
  13. Phan-udom, Purit; Wattanakul, Naruedon; Sakulniwat, Tattiya; Ragkhitwetsagul, Chaiyong; Sunetnanta, Thanwadee; Choetkiertikul, Morakot; Kula, Raula Gaikovina (2020-09-05), Teddy: Automatic Recommendation of Pythonic Idiom Usage For Pull-Based Software Projects, arXiv: 2009.03302