In this tutorial I am going to give you a gentle introduction to network programming in Python. If you are new to programming or new to Python then that may seem like a daunting thought. But read on and you will be pleasantly surprised how easy it is.

Like most modern programming languages, Python was designed for networking from the very beginning, and thanks to that, a lot of the networking tasks you would want to accomplish with the language are made a whole lot easier.

Network communication is a large topic, but if it is something that interests you then read on because in this tutorial I will show you how to download a web page. I will show you how easy Python makes tasks like this.

Take a look at the following code:

import urllib
	
con = urllib.urlopen("http://hartmannsoftware.com")
page = con.read()
con.close()
print page

Jeff Nelson, a former Googler and inventor of Chromebook says on Quora, “One habit I've clung to is writing small prototypes when I'm trying to learn new concepts.
For example, I'll sit down with a book or a web page, and over the course of a few hours, write 30 or 40 programs all of them only a few dozen lines long.  Each program intended to demonstrate some simple concept. This prototyping makes it very easy to try out many concepts in a short period of time.”

Miguel Paraz, Software Engineering Student habit is to “keep a log in a text file or document on my work computer. Before trying to solve a problem, I write it down first. And then I describe the details as they happen.”

The Zen of Python, by Tim Peters has been adopted by many as a model summary manual of python's philosophy.  Though these statements should be considered more as guideline and not mandatory rules, developers worldwide find the poem to be on a solid guiding ground.

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!

Attempting to create an intelligent entry about Linux for such a wide ranging audience is a bit like trying to compare a presentation on quantum mechanics for physicists while being readable by somebody with a junior high school education.

If you are a *NIX expert, then I suggest you keep on reading so you know how to explain this world to mere mortals.

I called it *nix for a reason. It represents a family of thinking. It is not unlike the difference between the language C and C++. Are there differences between the two? Certainly. And it is not like the difference between COBOL and C.

Years ago when I ran my own vo-tech school I would teach the students there are only two things in life. MS and *NIX. A friend of mine, a genius developer in her own right was aghast.