Recently, I asked my friend, Ray, to list those he believes are the top 10 most forward thinkers in the IT industry.  Below is the list he generated. 

Like most smart people, Ray gets his information from institutions such as the New York Times, the Wall Street Journal, the Huffington Post, Ted Talks ...  Ray is not an IT expert; he is, however, a marketer: the type that has an opinion on everything and is all too willing to share it.  Unfortunately, many of his opinions are based upon the writings/editorials of those attempting to appeal to the reading level of an 8th grader.  I suppose it could be worse.  He could be referencing Yahoo News, where important stories get priority placement such as when the voluptuous Kate Upton holds a computer close to her breasts.

Before you read further, note that missing from this list and not credited are innovators: Bill Joy, Dennis Ritchie, Linus Torvalds, Alan Turing, Edward Howard Armstrong, Peter Andreas Grunberg and Albert Fent, Gottfried Wilhelm Leibniz/Hermann Grassmann ... You know the type:  the type of individual who burns the midnight oil and rarely, if ever, guffaws over their discoveries or achievements.

This section of our beginning python training class always stumps students.  Firstly, because they need to know the difference between a function and a method.  Secondly, they need to understand object oriented programming concepts.  Thirdly, they need to realize that python has three types of methods.  Then they need to know how to use each method, which means they need to know the purpose of each method type.  Then they have to understand mutable versus non-mutable types.  The list goes on.  As part of our python tutorial, I hope to shed some light on this confusing topic.

To begin, the difference between a function and a method in python is that a method is defined within a class.  Here is an illustration:

#function

	def greeting():
	                print "Hello, I hope you're having a great day!"

	class HSGPrinter(object):
	                #method
	                def greeting(self): 
	                                print "Hello, I hope you're having a great day!"

As should be obvious, the second definition of greeting is encapsulated within the HSGPrinter class and is , therefore, refered to as a method.

The astute reader will notice that the greeting method contains one parameter named self.  For those who know C++ , Java or C#, self is equivalent to this i.e. it is a reference to the invoking object:

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

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!