[Twisted-Python] Freevo 2.0, Kamaelia, pyevent, Eventnet/LGT: what's going on?
Valentino Volonghi aka Dialtone
dialtone at divmod.com
Thu Oct 20 21:34:15 EDT 2005
On Fri, Oct 21, 2005 at 03:05:16AM +0200, Antoine Pitrou wrote:
> 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.
Point taken. But still this doesn't explain why few people submit bugs for
documentation and help in fixing them.
> Ok, but Twisted is much much more than a simple event loop.
Only because it has a lot of protocols already implemented, which you don't
use and hence make twisted a simple event loop from your perspective.
> 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
Still it is Open and not proprietary.
> 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".
What does: 'a fragment of existence of a Truck' mean? Is lifetime specified in
the name? Do we need to change the name of a class depending on how long it
Not at all.
A class is the type of something. Explains the behaviour and initial state of
a something, frozen in time. The fact that one particular instance (or even
all of them) survive only one connection has no reflection on the object
Also because protocol lifetime is also completely in your hands. By default it
only lasts one connection, you may keep it live for the whole application
life and even reuse it from the factory for later connections.
The protocol instance is created in the Factory. Twisted gives you the chance
to make decisions in that precise moment.
> 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.
Understanding an event loop and how it is exposed to the user is part of the
abstraction level. You don't need to know that twisted buffers communication
or that it accepts 50 connections at a time. Except when you are really
dealing with that stuff. In which case this should be documented and maybe it
isn't as much. Yet for most cases you don't need to know those details.
> That doesn't tell me a separate Protocol instance is created for each
> Having to rely on such "hints" is like playing Russian roulette.
The fact that the factory is the thing that creates the protocol, and thus has
the main word on how long it will survive and how it will be used, should just
be a big alarm on that.
> 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.
This is indeed sad.
> 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.
Why? Things are never reusable in such an easy way.
> 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.
This is the future. Now it's different. And the future includes the ternary
> 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 ;)
Maybe. Still makes me sad though (more complexity instead of more simplicity,
as the boss hints for a reason to not use twisted, as you are hinting too).
> 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.
There are criticisms and criticisms. Yours is very well accepted and will be
considered if it will end up in a bug submission or some help in fixing the
bugs you see in documentation. Just saying: 'there is few' doesn't help much,
maybe we already know that not everything is perfectly documented. Taking a
bit of your time to write a small summary of where the documentation is
lacking and a small comment on how to fix that instead will be answered and
fixed most probably.
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 186 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20051021/bb5cbcb5/attachment.pgp
More information about the Twisted-Python