Python Culture

Each software project has its own culture and style, its own approach to solving problems. Python has its own distinctive style, of course, and if you're a Python user, that style has probably rubbed off on you to some extent. Python tries to keep things simple, to be orthogonal but not too much so, and to assist the programmer as much as possible.

The first and most important thing is to be friendly, even (I should say especially) with people who disagree with you. Other people are not idiots just because they disagree with you, so don't call them idiots. Rudeness and flaming, especially on python-dev, is a fast way to get ignored. Have a sense of humour, and don't take things too seriously.

Another useful skill is to know when to give up. If a thread has gone on for dozens or hundreds of posts with no clear consensus emerging, one of two things will happen. Either Guido will make a BDFL pronouncement, which consists of him saying "We'll do it this way", or he's given up on the thread and isn't reading it at all any more. In either case, there's little point in continuing the discussion.

Design Principles

In June 1999, Tim Peters channeled Guido and listed 19 guiding principles for Python's design in a comp.lang.python posting. The principles shouldn't be taken too seriously, as they're not hard-and-fast constraints and for each rule you can probably list instances where it's been broken. Still, no one has had much disagreement with this list of design criteria.

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!

Don't take these 19 aphorisms too seriously -- tattooing them on your body is probably a bad idea, for example -- but it's instructive to contemplate them. Some parallels can be drawn to the guiding principles of extreme programming, most notably the emphasis on "Do the simplest thing that can possibly work".

Another principle is "Correctness and clarity before speed." Most of the code in the Python interpreter and standard library is written in a very straightforward style. The developers aren't interested in making the interpreter run faster at the expense of unreadable or hard-to-follow tricky code. In the past working patches have been rejected because they would have made the code too difficult to maintain.