Comments (largely compiled by Markus Demleitner)

While learning python is great, having programming skills is even better. Here, are mentioned a few of the virtues that will make you a good programmer.

Read – Reading is the most important skill for writing programs.

Read error messages – Good error messages actually tell you what's wrong. If you don't understand them, try to get an understanding. That's one of the cases when it's a good idea to google an error message. Do not blindly edit until an error message goes away.

Read documentation – Python's library documentation (http://docs.python.org, or the python-doc package on most open system for local usage) is fairly good and readable. Before you use a module, skim over its docs, before you use a function, have a look there (and see below for ipython's ?). Refuse the temptation to guess.

Read other people's code – Programming is non-obvious. Just as you have to read novels to write good texts, read and try to understand code passed to you (or perhaps just library code, which tends to be „good” in one way or another). The least it will do is show you what not to do if you'd like other people to understand your program.

Plan what you write, i.e., think a bit about what you want to write. Putting it into a little text doesn't hurt at all (sentences of that text could become functions). But be aware that you probably thought wrong and you may have to throw away prototypes later. Programming is non-obvious, in particular with hard problems, you won't get it right the first time.

Think before copying code. It is not easy to resist the temptation to blindly google error messages and code snippets. There is some serious expertise on stackoverflow. But at least one has to try to understand what the snippet is and does before pasting it. And whether it actually fits the problem at hand.

The Zen of Python

A text on the philosophy of programming is built right into your python interpreter:

import this

The Zen of Python, by Tim Peters

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!