As of version 0.6.2, Pyrite no longer places its compiled modules in a
platform-specific subdirectory (eg. "plat-linux2" on Linux systems).

Originally, this appeared to be a good idea because it seemed that it
would allow the same Pyrite installation to be shared across
architectures, with each machine getting the proper set of shared
libraries.  In practice, though, it doesn't really work that way.

The problem, basically, is that sys.platform doesn't provide enough
granularity: it describes only the general type of OS the interpreter
is running on.  This is adequate to deal with the sort of OS
differences that might affect Python code -- differences in system
call semantics, for example -- but is not enough to describe the
sort of differences that would affect the loading of shared
libraries.

For example, Linux runs on multiple hardware architectures.  In some
cases (Debian and Red Hat come to mind) it is possible to use the same
distribution on several different architectures.  If I install Debian
GNU/Linux on both a PC and an Alpha box, the runtime environment will
be essentially the same... right down to Python calling both systems
"linux2", even though they will not run the same compiled modules.

It is interesting to note, in fact, that the Python distribution makes
no attempt to use sys.platform to separate compiled modules.  It just
puts them all in sys.exec_prefix+'/lib/python1.5/lib-dynload'.  The
standard Python library contains platform-specific subdirectories, but
these contain only Python code, the sort of stuff that can be
distinguished by sys.platform.

As a result, I have decided to stop using the platform-specific
directory for Pyrite's compiled modules.  I can always revive it
later, if there is a need for platform-specific Python code in
Pyrite.