Python 1.4, AADR9 version 1

Here's a nice port of Python 1.4 to BeOS AADR9, featuring:

* BeOS-native multithreading (using the thread module)

* dynamically loading modules

* every module that would compile, built as a shared library to keep the
  interpreter as small as possible

* the interpreter binary is also a shared library; to create a dynamically-
  loadable add-on module, you link against the python interpreter (see
  Demos/dynamic for an example)

The modules include:

* all the Python-based modules (of course!)
* array
* audioop
* binascii
* cmath
* crypt
* errno
* fcntl
* grp
* imageop
* math
* md5
* new
* operator
* parser
* posix (use it through the os module)
* pwd
* regex
* rgbimg
* rotor
* select
* signal
* socket
* soundex
* strop
* struct
* syslog
* termios
* thread
* time
* timing

KNOWN BUGS

BUG #1
I haven't really tested most of the modules too much; who has time?  The
interprter passes all of its internal tests (except the floating-point
calculations; those are expected to fail though, due to floating-point
rounding errors).

BUG #2
The socket module may or may not work correctly; BeOS doesn't implement 100%
of the BSD socket interface yet, so be sure to test it thouroughly before
you try using it!

BUG #3
In AADR9, if you load an add-on with the full path of the add-on (like
Python will try to do for dynamically-loaded modules), the current working
directory must be where the binary lives (in this case, the python
interpreter).

This is cheesy, and means two things:

1) if you build a module in your current directory, and try to load it
   into Python, it will fail

2) the dynamic import code has a silly hack in it to change to the directory
   where Python is installed, load the add-on module, then change back to
   the current directory

Take a look at Demos/dynamic for an example of a very simple dynamically
loaded module, plus everything you need to do to make it work (ie, type
"make" :-).

BUG #4 Not really a bug, but if you notice any weird behaviour that might be
related to this, please let me know...  *ALL* of the modules (and there are
a few... look in lib/python1.4/sharedmodules/) have been compiled with
"-export all".  That was the easiest way of getting all the right symbols
exported; I could've futzed around with "#pragma export on/#pragma export
reset" (and thus littering the code with compiler-specific crud that would
stun a dumb K&R compiler into unconsciousness) and/or export files for
hours.  It'd sure be nice if mwcc had an "-export nonstatic" option that
would behave like most UNIX compilers, and automagically export all of the
non-static symbols in a shared library...

The python interpreter was done "right" though, with an export file
(shamelessly stolen from the AIX port and edited to suit my purposes).

- Chris Herborth (chrish@qnx.com)
  June 1, 1997
