[Edu-sig] The annotated walky-talky
Arthur Siegel
siegel@eico.com
Sat, 8 Apr 2000 19:01:44 -0400
Sorry for the successive posts. But I'm a little pumped about an
effort at a very annotated (but executable) version of David Sherer's
walky-talky. Again, I'm doing it with my son in mind. Thought I'd
put it up in progress, and hope for some feedback. Can't go further
anyway until I understand the socket stuff better myself:
# Primitive Walky-talky (sp?)
# Based on the example code for 'socket' in the Python
# library reference. code by David Sherer.
# We are creating a script to be read by the Python interpreter.
# We need only know how to talk to Python. Python inteprets to the
# machine. My own understanding of how is sketchy at best. But it's
all
# in layers. Python itself relies on another layer below it (the
# C programming language) to interpret for it. We can get a lot done
as
# a programmer without having to understand everything happening all
the way
# down the pipe.
# Python knows that anything written on a line after a '#' is just
talk,
# and will ignore it - which is why I can tell you about
# the program in the program itself. Most programming languages
provide for
# some mechanism like this, so that a programmer can leave notes
explaining
# what they are doing. Everything below not proceded by a '#' is
actually
# programming code.
# The first thing we are doing is making some additional intelligence
# available to our program script - specifically some intelligence about the
# communications protocol known as sockets, a technology underlying
# the entire Internet.
from socket import * # makes all classes of the socket module available
to
# this script. '*' is a symbol which by convention
tends
# to mean 'all'. Python follows that convention.
# The sockets module is itself a Python program script, much like our own,
located somewhere
# on our hard drive in a place that the Python interpreter knows to search.
It knows
# because one way or other its been told - but let's leave how aside. Just
know its easy.
# And if the script can't be found we will get an error message telling us
so when we try to run
# the program.
# The sockets script takes on the hardest part of using sockets - and
leaves us hooks
# in to its logic for accessing internet communication functions from
Python. Those
# hooks are the socket modules 'classes'.
# The ability to use and build upon classes from outside sources
# with great flexibility is one of the distinguishing characteristic of an
# Object Oriented Programming language like Python. I couldn't write a
sockets module
# if my life depended on it, but with some effort I could learn to use
someone else's
# module - especially if they left me a decent trail about how to do so.
# What I'm trying to get across probably isn't clear yet. Hopefully it will
begin to get clearer as we go.
# Took me a few paragraps to try to begin to explain it - three words and a
symbol to
# actually do it. Which is one of the things I like about programming. A
little can do a lot.
# The next three lines of code aren't even strictly necessary.
# We are assigning nicknames to some information used later in the
# program. We just use the nickname in the rest of the program.
# Now, if we want to change the information, we change the meaning of the
nickname
# and that information changes everywhere the nickname is used. Convenient.
HOST = 'localhost' # Computer to connect to
LOCAL = '' # Symbolic name for localhost
PORT = 50007 # Arbitrary non-privileged server
# The nickname is to the left of the '=', the actual information that Python
will see
# when we use the nickname later in the script is to the right. The
nicknames
# would be called 'global variables' (though I wouldn't worry much about
terminology - its called
# something else in French, something else in Hebrew, etc - so to me what
they happen to be called in
# English is probably the least interesting thing about them. A triangle
only has three sides if
# you happen to be speaking English. Got that out of my system.)
# By convention the globals are in all caps - just to make the code easier
to follow
# for others who know the convention. Python,though, won't complain if
they're not all caps.
# When using words or letters that we want to send down the pipe, they are
usually entered
# in quotes (single or double). If a word (on the right of the '=') is
entered without quotes, Python assumes
# it is a word it already knows about - either because the word is one
built-in to the language or because
# we had previously provided it with a meaning. If we take the quotes off
'localhost', the program will stop with an error
# when it gets to it - saying it doesn't know anything about that word. It
happens that the word 'localhost'
# means something in particular to sockets, which is why its being used -
but it means nothing in particular to
# Python itself. We will just be using Python to mechanically pass it along
'as is' done the pipe to the socket.
# HOST (to the left of '=') is not in quotes because we are in the process
of giving
# it a meaning. And, it is not in quotes when used later, because it now
has a specific meaning to Python -
# whatever we assigned it to mean.
# Numbers which are to interpreted as numbers are entered without quotes.
But you couldn't use a number
# on the left hand side of '=', because Python won't let you change the
meaning of a number.
# LOCAL is defined as '', two single quotes with nothing in between - a way
of saying 'nothing' or 'empty'.
....