Python Philosophy

The Zen of Python, by TimPeters:

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.
1. Although practicality beats purity.
Errors should never pass silently.
1. 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.
1. Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
1. 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!

EasterEgg: If you have Python 2.1.2 or later you can read the Philosophy of Python whenever you want. Just do the following:

 $ python
 Python 2.2 (#1, Apr 17 2002, 16:11:12) 
 [GCC 2.95.2 19991024 (release)] on some-os
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import this

I would add "16. OOP is The Way," as it's very difficult to get away from ObjectOrientedProgramming when using PythonLanguage.

Not so. If you omit the class word from your Python, you can very merrily def your way into something that looks a lot like PascalLanguage. In fact, before I grokked OOP, I did just that. -- SeanOleary

True, but when you def a function, you define an object of type function; so OOP it is:

 >>> def foo(x): return x

 >>> type(foo)
 <type 'function'>
 >>> foo.__class__.__name__
 'function'

-- Kirby

Functions are objects, but that doesn't force ObjectOrientedProgramming. You can easily write non-OO code in PythonLanguage without caring that the interpreter happens to internally represent your functions as objects.

The object-based standard library does make it hard to do much without knowing something about objects. -- CarlMeyer

I use the term "Thing-Oriented Programming" when describing PythonLanguage during some of my more whimsical moments. The idea is that everything that you create or define can be casually handed around as if it were an ordinary variable. This applies not just to objects, but to class definitions and function definitions. It's not a 100% accurate analogy, but it seems good enough to make the light bulb go off for some folks who are expecting another ObjectOrientedProgrammingLanguage. -- BrianWisti

Am I the only person who keeps seeing this page name and expecting to find the Australian philosophers' song from MontyPython? (See http://www.hicom.net/~oedipus/books/philo.html for the text.) -- GarethMcCaughan Yes! I am an Australian philosopher, and even I don't expect that! -- JasonGrossman (sorry: BruceGrossman?) No one expects the Australian philosophers' song!

Please see also http://www.python.org/dev/culture/ (it contains a few more aphorisms, including "Do the simplest thing that can possibly work" and "Correctness and clarity before speed.")

There should be one-- and preferably only one --obvious way to do it.

A.K.A. TheresOnlyOneWayToDoIt?

Then why is it that on so many pages there are far fewer PerlLanguage examples than PythonLanguage examples? (e.g. BagSumInManyProgrammingLanguages).

Because Python's consistency and simplicity (without sacrificing power) allows you to concentrate on the problem. This often allows you to try alternate algorithms.

Seems to me that ThereIsMoreThanOneWayToDoIt is compatible with Python: there are an infinite number of ways to do nearly everything, and one of those ways is the PythonWay?. Python serves its purpose in the OpenSourceEcosystem?. There is no one right way to live. There is no one right way to program. --naught101

CategoryPython