Python Design Philosophy - Guido van Rossum (Part 1)

This is the first part of an article from the official blog of the author of our favorite language. Therefore, the story is on behalf of Guido van Rossum himself. The second part is here .

The following text will help us dive deeper into the history of the Python language. However, before we do this, I would like to focus on philosophical things that helped me make decisions while I was developing the design and structure of Python.

First, Python was initially positioned as an indie project that only one person was involved in - there was no official budget, and I wanted to achieve results as soon as possible, so, in particular, an important step was to convince management of the need to support the project (in which I was pretty successful). This led to a number of rules that saved valuable time:

- Borrow ideas from wherever it makes sense.
- “Things should be as simple as possible, but not simpler than that.” (Einstein)
“If you do one thing, do it well (UNIX Philosophy).”
- Do not bother about performance - it can be optimized in the future, if necessary.
- Do not fight with iron, but just go with the flow.
- Do not try to achieve perfection, because “well enough” is often exactly what you need.
- (This way) you can sometimes cut a corner, especially if you can solve this problem later.

The remaining principles were not so economical with respect to time. Sometimes there was even the opposite effect:
')
- Python structure should not be tied to a specific platform. Nothing, if part of the functionality will sometimes be unavailable, but the foundation should work always and everywhere.
- Do not load the user with details that the machine can solve on its own (I did not always follow this rule, and some of the disastrous consequences of this will be described below).
- Support and encouragement of platform-independent code, but you shouldn’t cut access to specific features of the platform (This, by the way, contrasts sharply with Java.)
- A large complex system must have multi-level extensibility. This increases the possibility of users, no matter how confused it may sound, to help themselves.
- Errors should not be fatal. This means that the user code must be able to survive everything while the virtual machine is still able to work.
- At the same time, errors should not go unnoticed (the last two things really led to the decision to use exceptions during structuring).
- An error in the user code should not be given a chance to lead the Python interpreter to malfunction; a kernel crash should never be a user error.

Thus, I had a lot of ideas for creating a good construction for a programming language, and they greatly influenced me while working in the ABC group, where I gained my first experience in implementing and structuring the language. These ideas are difficult to describe in words, since they mostly revolve around such subjective things as elegance, simplicity and readability.

Although I’m going to talk in more detail later about the impact of ABC’s experience on Python’s development, I’d like to mention one rule regarding code readability separately: punctuation marks should be used “conservatively,” according to their usual use in written English or higher school algebra. Exceptions should apply only to things that have become a tradition for programming languages, such as “x * y” for multiplication, “a [i]” to refer to an array element, or “x.foo” attribute selection, but Python does not use either “$” To designate variables, and “!” To denote negation in operations.

Tim Peters, who has long been a dedicated user of Python and then became the most prolific and tenacious developer, attempted to combine my fragmented structuring principles into something he called Zen Python . I will quote it here in its entirety:

- Beauty is better than ugliness.
“Clarity is better than ambiguity.”
- Simplicity is better than complexity.
- Complexity is better than confusion.
- The plane is better than nesting.
- Diluted better concentration.
- Readability is much appreciated.
- Special cases are not so special as to violate the rules for their sake.
- Although practicality above neatness.
- Errors should not go unnoticed.
- If the error is not in stealth.
- In the face of uncertainty, it is better to give up trying to guess.
“There should be one — and it would be ideal if only one is the obvious way to solve the problem.”
- Although at first glance this method may not seem obvious, especially if you are a Dutchman.
- Now is better than never.
- Although often never better than right now.
- If the structure is not easy to explain - then this is a bad idea.
“If the structure is simply explained, it might be a good idea.”
“Namespaces are a really damn good idea — let's make them bigger!”

Although my experience in ABC had a great influence on Python, the ABC group had its own structuring principles, which were radically different from python ones. In many ways, Python deliberately seriously moved away from them:

- ABC group strived for excellence. For example, they used algorithms using tree data structures (asymptotically optimal, but not very fast for small volumes).
- ABC group wanted to separate the user, as far as possible, from the “big evil world of computers”. There should be not only a limit to the size of the numbers, the length of the lines, or the size of the data sets (of course, within the total available memory), but users should also not need to poke around in files, disks, “save” or other programs. ABC should be the only thing they need. This postulate also led the ABC group to create a complete integrated environment editing tool unique to ABC (Of course, it was possible to “get out” from the ABC environment, but this was only secondary, and was not considered from the point of view of the language itself.)
- ABC group believed that users are not required to have any computer experience (or wanted to lose it (:) - Approx. Translator)). Thus, alternative terminology, as they believed, should have led to a structure more “friendly for beginners” than in other programming languages. For example, procedures (procedures) were called “guides” (“how-tos”), and variables (variables) - “ways”.
- ABC group structured ABC without any special development plans, and without much hope of user support. ABC was created as a closed system, as flawless as the developers themselves considered it as such. Attempts by the user to “look under the cover” were discouraged. Although there was talk about opening specific sections of the system structure “for advanced users”, it was never implemented in the future.

In any case, the structuring philosophy that I used in the development of Python clearly served as one of the reasons for its, frankly, outstanding success. Instead of “striving for perfection,” the first followers found that it works “well enough” to solve their usual tasks. Simultaneously with the increase in the user base, suggestions for improvement were included in the language. As we will see in later publications, many of these improvements have led to quite serious changes and reworking of the root part of the language. Even now, Python continues to evolve.

(c) Guido van Rossum