Python, design philosophy - Guido van Rossum (part 1)

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

Further 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 Python design and structure.

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

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

The remaining principles were not so economical in relation to time. Sometimes there was even a direct opposite effect:

- The Python structure should not be tied to a specific platform. It’s fine if part of the functionality is sometimes 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 catastrophic consequences from this will be described later).
- Support and promotion of platform-independent code, but do not cut off access to specific platform features (This, by the way, is in sharp contrast with Java.)
- A large complex system should have multi-level extensibility. This increases the ability of users, no matter how confused it may sound, to help themselves.
- Mistakes 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 bunch of ideas for creating a good design for a programming language, and they influenced me a lot during my work at 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 mainly revolve around such subjective things as elegance, simplicity and readability.

Although I’m going to talk a little later about the effect of ABC experience on Python development, I would like to mention one rule regarding code readability separately: punctuation should be used “conservatively”, in accordance with their usual use in written English or high school algebra. Exceptions should concern only things that have become a tradition for programming languages, such as “x * y” for multiplication, “a [i]” for accessing an array element, or “x.foo” attribute selection, but Python does not use either “$” To denote variables, nor “!” to denote negation in operations.

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

- Beauty is better than ugliness.
“Clarity is better than obscurity.”
- Simplicity is better than complexity.
- Complexity is better than confusion.
- The plane is better than nesting.
- Divorce is better than concentration.
- Readability is much appreciated.
- Special cases are not so special as to violate the rules for them.
- Although practicality is higher than neatness.
- Errors should not go unnoticed.
- If the error is not in invisibility.
- In the face of uncertainty, it is better to abandon attempts 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 Dutch.
“Better now than never.”
“Although often never better than right now.”
- If the structure is not easy to explain, then this is a bad idea.
“If you simply explain the structure, it might be a good idea.”
“Namespaces are a really damn good idea — let's make them bigger!”

Although my experience at ABC had a big impact on Python, the ABC group had its own structuring principles that were radically different from python ones. In many ways, Python deliberately seriously departed from them:

- ABC group strived for excellence. For example, they used algorithms using tree-like data structures (asymptotically optimal, but not very fast for small volumes).
“The ABC group wanted to separate the user, as far as possible, from the“ big evil world of computers. ” Not only should there be no limit to the size of numbers, the length of lines, or the size of data sets (of course, within the total available memory), but users should also not have to poke around in files, disks, “saves” 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" of 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 were not required to have any computer experience (or wanted to lose it (:) - Approx. Translator)). Thus, alternative terminology, they believed, was supposed to lead to a structure more “novice friendly” than in other programming languages. For example, procedures were called “how-tos,” and variables were called “paths.”
- ABC group structured ABC without 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 covers” were not encouraged. Although there was talk about the opening of special sections of the structure of the system “for advanced users”, this was not implemented in the future.

In any case, the structuring philosophy that I used when developing Python was clearly one of the reasons for its, frankly, outstanding success. Instead of “striving for excellence,” the first followers found that it works “well enough” to solve their usual problems. Along 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 entailed quite serious changes and a revision of the root of the language. Even now, Python continues to evolve.

(c) Guido van Rossum