[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'.


....