This is an idea I got thinking about COM objects, and getting some support from Mark Hammond, Python's Win32 wizard.
The goal is to have a host language (not Python) instantiate an object that runs against the Python interpreter, which lives as its own process. The VMs have various ways of implementing this. Mono isn't that different right? In this design pattern, you have something like a dry cleaner's, where people submit jobs at the counter, and go away right away with a ticket (Python returns -- but keeps running). When they come back is more up to them. Work has been done in the meantime (or not, if the queue is backed up). So Python needs a queue in the front, to accept these job orders, a facility for issuing tickets, and a way to catalog what tasks are completed in some urn or receptacle (given this is Python, we might call it a "holy grail"). The host process has a method from querying the Python object as to whether such-and-such a job is complete or not. More primitively, it could just check an output bin (folder) for the expected file (perhaps each "hair" creates a PDF in roughly 1 to 4 seconds). The reason "Medusa" is useful wordplay is it reminds us of the asynchronous server embedded in early Zope. How Medusa relates to Twisted is lore for others to recount. However, given we're spawning strands, hairs or threads each time a host process calls into our object, we're looking at a multi-snaked environment, so the image could hardly be more apt. The act of "combing" suggests some synchronization / communication between threads, but that's not a requirement. More on tap here: http://mail.python.org/pipermail/edu-sig/2010-December/010141.html Kirby -- http://mail.python.org/mailman/listinfo/python-list