[Tutor] Is Python fast enough and capable of.. ?

Tim Nall mrnall@hotmail.com
Sun, 20 Aug 2000 14:44:25 -0500


Hi All,

My name is Tim Nall. I am in St. Louis, Missouri, USA.

I am an utter newbie, *both* to python and to this list. If there is a
FAQ I should read before posting, please avert your eyes from any faux
pas I may commit, and point me in the proper direction.  :-)

I want to ask a very long and involved question. I'm asking this because
-- if python is inappropriate for the programming task I must complete,
then (unfortunately) I need to move on to another scripting language
immediately. Please forgive me if this seems impolite. I am somewhat
squeezed between a rock and a hard place.  :-)

By the way, unforunately I also have no knowledge of any other scripting
language (PERL, etc.) I am thinking that Python is the way to go because
of its allegedly kinder, gentler learning curve, and the ease with which
other programmers should be able to maintain or extend this at a later
date.

If you have trouble reading the following info, I sympathize. I had
trouble writing it. I am in fact embarassed by the necessity of imposing
so tremendous a set of questions upon strangers. However -- I need my
job. :-)

In fact, I'm aware that the entire message that follows might very well 
be considered inappropriate by some people on some lists. If that is the
case for the gentle readers of this list, again I ask you to lower the
curtain of grace over me and my posting. :-)

I have been asked to write a (Python?) process which would accomplish
the following in a very fast and robust manner. The nontrivial
difficulties presented from the following scenario are mostly caused by
the inability of users running PICK programs against a PICK database to
communicate with anything other than that PICK database.

So here goes:

I am the only programmer at a business which is very phone-oriented.
This business uses a PICK database which resides on a UNIX system.
Tomorrow I will get hardware and shell information about the UNIX
system; I do not have it at this moment.

Please note that I am embarassingly ignorant of many important details
about the task I have been asked to accomplish. In particular, at
present I have little or no info about the phone system posited below.

Assume the presence of a phone system which, upon receiving an incoming
call, extracts info such as the caller's phone number (and perhaps other
info, entered by the caller on a touch-tone phone), and sends that info
to a particular port (we'll call it port #239) in string format. 

Assume a (Python?) process which must continuously perform all three of
the following:
1) Listen at Port #239 and receive the incoming strings. Note that at
peak business-time this may involve receiving and processing perhaps as
many as 150 or 250 incoming calls (i.e., strings from the phone system)
in an apparently simultaneous manner.
2) Upon receiving strings, write them out immediately to a UNIX file in
a prescribed manner.
3) Perhaps (??) it may be necessary to immediately return that string to
the phone sytem for the phone system's use.
4) Check a UNIX directory for newly-written files (details described
later in this message). If it finds any UNIX files which are intended
for reading by the Python program (as determined by file location and/or
file name) it must:
  A) read that UNIX file, 
  B) extract a string of info, and 
  C) pass that info back to the phone sytem. 
UNIX files intended for the Python process to read might (for example)
be written out by a PICK program in response to a user's decision to
forward an incoming call.

Assume many users at dumb terminals, utilizing PICK programs against a
PICK database. These users are *not* capable of reading from or writing
to UNIX files. They are not capable of receiving strings sent by the
phone system.

At this point it seems necessary to assume a continuously-running PICK
program on a PC. This program is capable of reading from and writing to
*both* UNIX and PICK files, to act as a link between the incoming info
(on UNIX files) and the PICK database (and hence, to the users at their
dumb terminals). The PC is *not* capable of communicating directly with
the phone system (i.e, is not capable of sending a string to a given
port). The PICK program running at this PC is not capable of listening
to a given port for information.

Writing the necessary PICK program to process UNIX and PICK files is not
considered to be an obstacle.

So the scenario  is as follows:

A) Incoming calls reach the phone system.
B) Phone sytem sends string to port #239 where it is grabbed by the
Python process.
C) Python process gets specific info from string (phone number, perhaps
other info as entered by caller) and writes info out to a UNIX file. It
may also (??) be necessary for the Python process to immediately return
that string to the phone system.
D) A PICK program running on PC reads the newly-written UNIX file, again
extracts necesary info, performs other operations which are irrelevant
to the task of the Python process, and finally  writes related info out
to a PICK file which is accessible by the users at their terminals.
E) A given users chooses to access the info (that was just written by a
PICK program to a PICK file) when his/her phone rings. Info includes
customer name, location, etc. This info is displayed on the terminal.
The info is acompanied by a list of options, including "forward this
call to another user, forward to voice mail.." etc.
F) If the user must communicate with the phone sytem, his/her response
will be written out to a PICK file, which is read and processed by the
PICK program running continuously on a PC, which then writes info out to
a UNIX file, which is then read by the Python process, which forwards
the string to the phone system.
G) Repeat steps A through F continuously.

Whew!

Any and all comments by people kind and brave enough to do so will be
deeply appreciated. My first question would be, "Is this doable, in a
timely manner?" Other questions would follow, I suppose.

Many thanks for your supreme kindness and patience,
Tim Nall