[PATCH] Branch and pull-- now with remote

David Allouche david at allouche.net
Tue Jun 7 16:26:55 BST 2005


On Tue, 2005-06-07 at 10:52 -0400, Aaron Bentley wrote:
> Basically, I think asychronous I/O sucks.  It's necessary for
> performance, but a pain in the ass to deal with.  This was an attempt
> to provide the minimum intrusion of asynchonicity, and letting most of
> the program treat the I/O as synchonous.

Yes, that's where I came from when we talked about this design. But the
goal then was trying to get asynchronous I/O benefits in a library
component without requiring changes the client code. Here the situation
is different.

Still, I agree that this design is good and useful. I'm just not sure
that implementing it is the best trade-off here.

> | If the point is doing efficient asynchronous networking, which it
> | appears to be, why not do it properly, and use Twisted?
> 
> Because people I respect have told me Twisted is crack.  Didn't you tell
> me that?

Yup. I did. But that was largely out of frustration with the buildbot
code base (which _is_ crack). Yet Twisted is full of crack, and I did
hit some bugs in their process handling code.

But that is still the best way to do asynchronous programming in Python.
Also, Twisted 2.0 (released recently), with its modular packaging, goes
a long way to restoring sanity.

> I also don't like the idea of having to rewrite a program to fit a
> framework, which my uninformed impression of Twisted.

That's my impression too. I think the issue is not specific to Twisted.
Properly event-driven state-machine programming is very different from
traditional imperative programming. I do not think you can really escape
that.

Do not understand this message as a Twisted fan pushing his favourite
piece of software. I am just pointing out that there is a design choice
to do here. Think about Tridge's presentation of linuxconf.au:

      * Threads are evil.
      * Process are ugly.
      * State machines send you mad.

There is a trade-off here to do between evil, ugly and mad. Preferably
with the minimum amount of wheel reinvention. But that minimum might be
pretty large. The ones who do the code decide, I'm just throwing
peanuts.

-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050607/9cd844fc/attachment.pgp 


More information about the bazaar mailing list