Scripting *of* Python

[Andrew Bennetts]

On Thu, Jan 30, 2003 at 06:20:15PM +0000, Phil Mayers wrote:
> On Thu, 30 Jan 2003 12:31:23 +0000, Aahz wrote:
> > 
> > Based on what you've said, I'd suggest looking into switching to
> > Twisted, http://www.twistedmatrix.com/products/twisted
> 
> I have seen Twisted. It seems to be a very popular recommendation in c.l.p
> of late ("I have incurable narcolepsy", "I recommend using Twisted" - :o)

Woo!  Looks like my recent efforts haven't gone unnoticed ;)

> However, the main problem is not with the async engine, which works fine,
> it's with the code that runs *inside* the async engine *looking like*
> async code.
> 
> My brain can cope with that - the people I'm writing it for probably
> cannot, and I'm being paid to come up with a solution that middle- to
> low-tier programmers can drive.
> 
> http://www.twistedmatrix.com/documents/howto/async
> 
> ...this document seems to imply that the only extra stuff Twisted gives
> you is the Deferred class/type for return values, which is basically
> what I've written in my engine. In fact, the Twisted doco more succinctly
> summarises the problem:
[..snip..]

Well, Twisted gives you *lots* of extra stuff (beyond what your average
person would consider relevant to something that claims to be a "networking
framework"...), but yeah, Deferreds are the most immediately applicable to
your problem.

> Yes, quite - but I don't think this state machine can be abstracted out to
> be "clear enough" - hence the scripting language and virtual
> multithreading suggestion.

Have you looked at the source to twisted.protocols.smtp.SMTPClient?  It's a
very simple and elegant way to do state machines in Python.  Note that it is
built upon twisted.protocols.basic.LineReceiver, which is another state
machine... hopefully this gives you some idea of how you can layer your
state machines in your own code.

> I will almost certainly switch to using Twisted if I can:
> 
> a) Shoehorn the virtual multithreading idea in, or find a better one
> b) Find the time before I need the code working
> 
> ...since it's clearly going to be better than an async engine I can write.

We like to think so ;)

-Andrew.