[Twisted-Python] Freevo 2.0, Kamaelia, pyevent, Eventnet/LGT: what's going on?
solipsis at pitrou.net
Thu Oct 20 21:05:16 EDT 2005
> I can't see how looking inside twisted.internet.interfaces is so hard. Also
> python is quite readable and twisted code is cleaner than the code of many
> other projects. I've never found any problems with learning how something
> works. And indeed I don't know how everything in twisted works. I often open
> examples, then I open the source code and so on. We live in the open source
> world. Use the Source Luke.
Understanding Python code is not very hard. But it merely tells me how
the thing works /now/. It doesn't tell me how it's supposed to work in
former/future versions, i.e. it doesn't give me a spec to program
against. I don't know which behaviour is an implementation detail and
which behaviour is part of the spec.
> Also design decisions
> are easily understood by anybody that tried to do the same thing alone. Most
> of the projects that deal with event loops are a simplified and poorer version
> of twisted.
Ok, but Twisted is much much more than a simple event loop.
> There is a java implementation of pb in the cvs tree. And by this POV I could
> say that also OpenDocument is proprietary because it is only implemented by
> OpenOffice 2.0.
Well, that is quite my opinion on OpenDocument right now. It is a
standard de jure, but de facto it is not interoperable at all (much less
than RTF or SXW). Of course we can be sure this will change for
OpenDocument, while this is less sure for PB (not the same
> It is eternal indeed. It's a class with some code in it. How much more
> ethernal could you be? instances are created and destroyed for each
When I write "class Protocol", it seems obvious that each instance would
be "a Protocol". The same way that if I write "class Truck", each
instance will be "a Truck". Not "a fragment of existence of a Truck
between two engine starts determined by an external Factory which is
semantically the real Truck".
Or, at least, it is the traditional "mind mapping" of object-oriented
I'm not saying this is a blocking problem, just that in the absence of
any clarification it is very misleading.
> In fact there is no magic, why should there be any documentation on something
> that there isn't? A framework is cool because mostly you don't need to worry
> about what happens below of the abstraction layer you are given.
I don't agree. Using a framework without trying to understand (even
roughly) what happens underneath is very dangerous. For example using
Twisted without knowing (even roughly) how an event loop works in
practice would not be a good idea.
> Why do you think protocols have a connectionMade and a connectionLost method?
> When are they called IYHO?
That doesn't tell me a separate Protocol instance is created for each
Having to rely on such "hints" is like playing Russian roulette.
Of course I took the simpler route of not caring /at all/ about it and
instead implementing all state and connection bookkeeping in my own
classes. Which means my Protocol/Factory classes are essentially empty.
> When you start a TCP connection a socket is added to the reactor. That's all.
That I understand perfectly :)
> But when coming to networking it just doesn't make any sense.
> There is no better alternative, if any then I'm more than happy to look at it
> and maybe start helping there instead of here. As all the frameworks when you
> use it you are stuck with it.
But at very different levels depending on your usage...
If I just use Twisted as a basis for having callbacks applied when an
UDP datagram is received, and handle all the rest by myself, it will not
be too difficult to change to another framework (assuming it allows
asynchronous-style programming of course ;)).
If on another hand I use the "full Monty" (twistd, PB, etc.), my app
will be very closely wired around Twisted and it will be very tedious to
rearrange it around another framework.
> Python sucks because it doesn't allow
> async and sync programming style to be merged togheter,
How do you want to merge them together ?
There has been various discussion on the Python-dev list and the general
sentiment has been "explicit is better than implicit". In other words,
don't make async tasks look like they are synchronous. I rather agree
with this. Too much magic often backfires brutally.
> Python subprocess module, compared to
> twisted's reactor.spawnProcess simply sucks. [...]
> My boss asked explicitly for a syncronous version of it.
Without knowing the precise problem to be solved, I'd say: launch the
Twisted event loop in a separate thread, and use threading.Condition to
signal the main thread. Or a subtle variation of it ;)
> But just saying that
> twisted is bad because it has few documentation and stop there, seems like
> whining :).
I've been using Twisted for one year and am generally satisfied with the
parts of it I've chosen to use. I was answering to the question of "what
people may find annoying in Twisted".
My advice is that you shouldn't take every criticism as just a proof of
laziness on the part of the critic. Even very terse critics like
"Twisted is a huge monster" can be valuable for you to guess what kind
of perception Twisted enjoys.
> Hope I've been not too harsh at as helpful and informative as possible.
More information about the Twisted-Python