Remote Procedure Call (RPC) interfaces, used in distributed systems like Amoeba [#!Amoeba:IEEE!#,#!Amoeba:CACM!#], have a much more concrete character than local procedure call interfaces in traditional systems. Because clients and servers may run on different machines, with possibly different word size, byte order, etc., much care is needed to describe interfaces exactly and to implement them in such a way that they continue to work when a client or server is moved to a different machine. Since machines may fail independently, error handling must also be treated more carefully.
A common approach to such problems is to use a stub generator. This is a program that takes an interface description and transforms it into functions that must be compiled and linked with client and server applications. These functions are called by the application code to take care of details of interfacing to the system's RPC layer, to implement transformations between data representations of different machines, to check for errors, etc. They are called `stubs' because they don't actually perform the action that they are called for but only relay the parameters to the server [#!RPC!#].
Amoeba's stub generator is called AIL, which stands for Amoeba Interface Language [#!AIL!#]. The first version of AIL generated only C functions, but an explicit goal of AIL's design was retargetability: it should be possible to add back-ends that generate stubs for different languages from the same interface descriptions. Moreover, the stubs generated by different back-ends must be interoperable: a client written in Modula-3, say, should be able to use a server written in C, and vice versa.
This interoperability is the key to the success of the marriage between AIL and Python. Python is a versatile interpreted language developed by the first author. Originally intended as an alternative for the kind of odd jobs that are traditionally solved by a mixture of shell scripts, manually given shell commands, and an occasional ad hoc C program, Python has evolved into a general interactive prototyping language. It has been applied to a wide range of problems, from replacements for large shell scripts to fancy graphics demos and multimedia applications.
One of Python's strengths is the ability for the user to type in some code and immediately run it: no compilation or linking is necessary. Interactive performance is further enhanced by Python's concise, clear syntax, its very-high-level data types, and its lack of declarations (which is compensated by run-time type checking). All this makes programming in Python feel like a leisure trip compared to the hard work involved in writing and debugging even a smallish C program.
It should be clear by now that Python will be the ideal tool to test servers and their interfaces. Especially during the development of a complex server, one often needs to generate test requests on an ad hoc basis, to answer questions like ``what happens if request X arrives when the server is in state Y,'' to test the behavior of the server with requests that touch its limitations, to check server responses to all sorts of wrong requests, etc. Python's ability to immediately execute `improvised' code makes it a much better tool for this situation than C.
The link to AIL extends Python with the necessary functionality to connect to arbitrary servers, making the server testbed sketched above a reality. Python's high-level data types, general programming features, and system interface ensure that it has all the power and flexibility needed for the job.
One could go even further than this. Current distributed operating systems, based on client-server interaction, all lack a good command language or `shell' to give adequate access to available services. Python has considerable potential for becoming such a shell.