Twill exports functions named the same as the twill commands, so I guess that's your "in process" requirement ticked...
In-process would mean that it calls an application in the same process, instead of generating an HTTP request. So an exception in the application would go all the way up to the command runner (py.test, unittest, etc).# Ian Bicking
Oh, I see, seems you're right.
You'd need a urllib2.HTTPHandler that does what you want instead of real HTTP, then subclass mechanize.Browser to override the handler_classes attribute, and persuade twill to use your Browser subclass.
It would be a clever hack to monkeypatch urllib2.HTTPHandler to override requests to certain hosts and instead send them to in-process WSGI applications. That would mean that any urllib2-using Python app should be able to work this way, including Twill or whatever else.# Ian Bicking
That's what I meant, but no "monkeypatch" is required: you just use a different handler instead of urllib2.HTTPHandler.
...oh, see what you mean -- it's the "persuade twill (or whatever) to use it" part that's troublesome. Sorry for spamming your blog so much ;-)