Mailman 3 March 2003 - Twisted

[Twisted-Python] Redirecting after form completion using woven
by Neil Blakey-Milner 07 Mar '03

07 Mar '03

Hi, Two things: Firstly, using Twisted 1.0.3, when form submissions has occurred, it seems that the getData to build the form is done before the setData to make the changes. This means that the _old_ information is in the forms, which is somewhat confusing. For an example, use stikiwiki and edit a page. It's entirely possible I'm using things incorrectly, though. Secondly, how would I organise for a redirect to another page after my form has been parsed and data handled with setData? Again, stikiwiki probably wants to redirect people to the page they've just edited or created instead of giving them an opportunity to edit it again. Thanks, Neil -- Neil Blakey-Milner nbm(a)mithrandr.moria.org

2 1

[Twisted-Python] PATCH: runQuery
by Federico Di Gregorio 07 Mar '03

07 Mar '03

while patching runQuery to solve my postgresql/psycopg problems i discovered a much problematic problem. essentially if a query run through runQuery raise an exception, the exception is propagated but rollback() is never called on the connection. this leaves the connection in a "dirty" state and the effects on the next query are database dependent (postgresql, for example, will simply discard all following queries until next rollback()). a patch follows: --- adbapi.py-old 2003-03-06 12:48:02.000000000 +0100 +++ adbapi.py 2003-03-06 13:02:33.000000000 +0100 @@ -94,9 +94,12 @@ def _runQuery(self, args, kw): conn = self.connect() curs = conn.cursor() - apply(curs.execute, args, kw) - result = curs.fetchall() - curs.close() + try: + apply(curs.execute, args, kw) + result = curs.fetchall() + curs.close() + finally: + conn.rollback() return result def _runOperation(self, args, kw): -- Federico Di Gregorio Debian GNU/Linux Developer fog(a)debian.org INIT.D Developer fog(a)initd.org Best friends are often failed lovers. -- Me

5 9

[Twisted-Python] Pending PendingDeprecationWarning
by Jp Calderone 07 Mar '03

07 Mar '03

As some may already know, Python 2.3 will see apply() change to a function implemented in Python and deprecated through the use of the PendingDeprecationWarning. While it will still be around for some time, as of 2.3 it will a stiff runtime penalty. I'd like to suggest that everyone use the new syntax when writing new code for Twisted, and if you happen to be making changes to existing code that uses apply(), to update these usages to the new syntax as well. I considered doing a monolothic patch to fix all current usages, but I think at least some of you will agree that an incremental approach is a better idea. Jp -- up 3 days, 15:58, 6 users, load average: 0.04, 0.05, 0.00

1 0

[Twisted-Python] gtk2reactor still broken?
by Abe Fettig 07 Mar '03

07 Mar '03

Hi folks, I just apt-get upgraded my python2.2-twisted (to verion 1.0.3+1.0.4alpha1) and python2.2-gtk2 (to version 1.99.15), and now the Twisted/GTK2 app I've been working on can no longer connectTCP - it gets a Timeout error every time. Last month there was some discussion about a problem with th gtk2reactor and the latest pygtk builds, but supposedly the problem was fixed (see http://www.twistedmatrix.com/ pipermail/twisted-python/2003-February/002762.html). It seems to me that the problem isn't fixed. As a test I did import gtk2reactor gtk2reactor.install() at the beginning of another twisted script, and it seemed to create the same problem. Is there anybody who is having success with gtk2reactor and the latest pygtk? -- Abe Fettig <abe(a)fettig.net>

2 1

[Twisted-Python] tap2deb -v/--version bug
by Tommi Virtanen 07 Mar '03

07 Mar '03

tap2deb --version option is overridden by global handling for --version that just displays the version number. [0 tv@lapdog ~]$ tap2deb --help Usage: tap2deb [options] Options: -u, --unsigned -t, --tapfile= [default: twistd.tap] -m, --maintainer= [default: ] -p, --protocol= [default: ] -e, --description= [default: ] -l, --long_description= [default: ] -v, --version= [default: 1.0] -d, --debfile= -y, --type= type of configuration: 'tap', 'xml, 'source' or 'python' [default: tap] --help Display this help and exit. tap2deb [0 tv@lapdog ~]$ tap2deb --version=42 -t foo.tap /usr/bin/tap2deb: option --version must not have an argument [1 tv@lapdog ~]$ Here's a patch that changes the option to --set-version=, and the short option to -V. Please tell if you approve this change. diff -u -u -r1.9 tap2deb.py --- twisted/scripts/tap2deb.py 3 Oct 2002 07:56:14 -0000 1.9 +++ twisted/scripts/tap2deb.py 4 Mar 2003 14:09:13 -0000 @@ -26,7 +26,7 @@ ["protocol", "p", ""], ["description", "e", ""], ["long_description", "l", ""], - ["version", "v", "1.0"], + ["set-version", "V", "1.0"], ["debfile", "d", None], ["type", "y", "tap", "type of configuration: 'tap', 'xml, 'source' or 'python'"]] @@ -54,7 +54,7 @@ base_tap_file = os.path.basename(config['tapfile']) protocol = (config['protocol'] or os.path.splitext(base_tap_file)[0]) deb_file = config['debfile'] or 'twisted-'+protocol - version = config['version'] + version = config['set-version'] maintainer = config['maintainer'] description = config['description'] or ('A TCP server for %(protocol)s' % vars()) -- :(){ :|:&};:

3 3

[Twisted-Python] coding standard: column width?
by Clark C. Evans 06 Mar '03

06 Mar '03

The (very clear) coding standards don't mention a preferred column width. Could it be possible to add a 76 column code wrap requirement. This is useful for those of us who use your aged 80 column terminals, and more importantly for those who want to forward/comment on code via e-mail. Most (95%) of the code is already following this rule, and it probably wouldn't take much effort to fix when people run into long lines that could/should be broken up. Clark

3 4

[Twisted-Python] Thoughts on Deferred
by Clark C. Evans 06 Mar '03

06 Mar '03

Ok. I've been using Deferreds some time now, actually I've coverted my report server to now use the mechanism as my core 'construction' model. I'd like to report some observations: 1. The entire deferred processing chain is quite nice, although the bulk of the time my callbacks don't take any arguments. I suspect that most people who do have callback args can just make an object and pass a bound method as their callback instead of the 'args' mechanism. This mechanism could be better supported by providing a wrapper class instead of maintaining all of the args throught the code: class DispatchCallback: def __init__(self, callback, args, kw): self.callback = callback self.args = args or () self.kw = kw or {} def apply(self,result): return apply(self.callback, (result,)+self.args, kw) Then, in addCallbacks, if any callback was given which had args or a kw, you could just construct this dispatch object and put the ob.apply into the callback stack. In this way only users who passed in callbacks with args pay for the penalty of applying them. 2. The error handling could use help. The cross-over behavior, while unique, doesn't provide any more value over a simple stack /w state flag (good/bad) attach to each callback. def _addCallback(self, callback, *args=None, **kw=None, state=good): if args or kw: callback = DispatchCallback(callback,args,kw) self.callbacks.append((state,callback)) Of course, existing functions can then be expressed as a sequence of addCallback /w state flag. addCallback => _addCallback(self,callback,args,kw,state=good) addErrback => _addCallback(self,errback,args,kw,state=bad) addCallbacks => addErrback(...); addCallback(...); It would have the same behavior since the current cross/over can easily be denormalized into two entries into the stack, one for a bad state (first) and then one for a good state (second). With these changes in place, _runCallbacks() is much simpler... 3. Deferred also "artifically limits" so that the entire callback tree can only be done once. This involves a hack "MultiDeferred" to solve the problem; but with a slightly different _runCallbacks plus a __init__ flag, this need not be the case. In short, the "multi-call deferred" that I need shouldn't be a separate class, its behavior can be rolled into the core Deferred without changing existing behavior (default to callOnceOnly). 4. Lastly, I'd like to see other "state" variables for the deferred. Essentially, what I see is a process flow, aka state transition mechnanism emerging. For an SQL query, one of the states is 'good', 'bad', and 'finished'. Perhaps I'm a bit off here, but being able to handle more than two states could be useful. I say this beacuse the MultiDeferred class has a addFinishCallback, which is fired on the 'finish' state. Note that errors in the 'row' callback and the 'finish' callback could possibly be treated the same, so there probably isn't a reason to split this... but maybye not.. I'm still thinking this one out. Just some thoughts. If you like, I could refactor the Deferred object as above (it'd be less code & probably cleaner), as well as updating the documentation and providing examples which run without modification. All in all, this is a great concept... and it's working beautyfully in my current application (mod the minor blemishes above). Best, Clark

3 7

[Twisted-Python] runQuery isolation patch
by Federico Di Gregorio 06 Mar '03

06 Mar '03

runQuery has a problem when used with databases with transactions and high isolation levels (like postgresql+psycopg): it never closes the transaction leaving threads using that connection from the pool completely isolated from changes to the database. the solution is to call rollback() on the connection just after the query has been executed. simple patch follows: --- adbapi.py-old 2003-03-06 12:48:02.000000000 +0100 +++ adbapi.py 2003-03-06 12:49:01.000000000 +0100 @@ -97,6 +97,7 @@ apply(curs.execute, args, kw) result = curs.fetchall() curs.close() + conn.rollback() return result def _runOperation(self, args, kw): -- Federico Di Gregorio Debian GNU/Linux Developer fog(a)debian.org INIT.D Developer fog(a)initd.org Gli esseri umani, a volte, sono destinati, per il solo fatto di esistere, a fare del male a qualcuno. -- Haruki Murakami

1 0

[Twisted-Python] newbie question about using deferreds
by Martin Waite 06 Mar '03

06 Mar '03

Hi, Twisted newbie here with a plan. Could someone please tell me if I'm barking up trees here ? In my application, I want to run a Twisted listener that collects incoming request messages and passes these to a thread that posts the message into a queue table in a database. Another thread polls the database for responses, and distributes these to the connections that made the corresponding requests. My understanding is that somehow I can do this using the Deferred mechanism - only I'm not sure how. My plan is to keep a global hash table of RequestID -> Deferred. When the listener identifies the end of a request, a deferred is created and stored against the RequestID. When the thread polling for responses from the database gets a response, it looks for a matching deferred from the global hash table and then somehow activates the deferred. Is this sane or am I missing an easier way to do this ? TIA, Martin

2 2

[Twisted-Python] Twisted.Web as scgi client
by Mike Müller 06 Mar '03

06 Mar '03

Hi, I am new to this list and twisted. I just played around with the howto setting up a web server with Twisted.Web serving static content, cgi and *.rpy. Works very nicely. I am impressed. I also like Quixote. Running it as a cgi script has all the overhead of starting everything again for each request. It would be nice to have Twisted.Web act as scgi client (http://www.mems-exchange.org/software/scgi/) that redirects all requests to, lets say, www.mydomain.com/askscgi to the scgi server that is run by Quixote. This way I can use all of Twisted.Web or Quixote when I want. Since the scgi protocol is designed to be implemented more easily than FastCGI somebody might already have done something like this. Or is it planned to be done sometime? Thanks Mike

1 0