Launching Multiple Servers

Andrew Bennetts andrew-pythonlist at puzzling.org
Fri May 23 21:14:37 EDT 2003


On Fri, May 23, 2003, Andrew Dalke wrote:
> Andrew Bennetts:
> > This is mainly conjecture on my part, but as far as I can tell, the main
> > reason why some people have trouble is they can't narrow down the docs and
> > examples to what matters most to them.  We have a fairly large amount of
> > terminology, which can leave people wondering "What the hell is 'reactor',
> > 'factory', 'woven', 'spread', 'pb', 'TAP', 'Deferred'..." (which is why I
> > wrote the glossary).
> 
> I, for one, agree with that.  I understand names like 'reactor' (because of
> Sam Rushing ;) and 'factory' - it's the Twisted-specific names which
> throw me for the loop.  "pb" means nothing to me.  I remember the
> reference to "peanut butter" which induced the names "jelly" and "banana",
> but then I forget which is which.  Even its expansion to "Perspective
> Broker"
> doesn't help me much.  I would rather prefer the name "Proxy Broker"...
> assuming that's what it does.

No, "Perspective Broker" is a sane name for it, as a PB server is a broker
for "perspectives".  There's now a doc regarding Perspectives that's not
tied to PB (they're actually a Cred concept), which might help you a little:

    http://twistedmatrix.com/documents/howto/pclients

Most people seem to find the PB docs adequate to comprehending at least
basic PB -- although I don't think the sandwich puns help many people.  Not
to mention the North American bias -- Australians like myself don't expect
to find jelly on a sandwich!

If you don't need a remote object protocol, you can safely ignore
twisted.spread, and it's associated sandwich modules.  (But for reference,
pb sits upon jelly sits upon banana...)

> >  And the
> > example code is very poorly categorised, and in places could do with more
> > comments describing what they demonstrate.
> 
> Or that the code does unexpected things.  I was experimenting with it
> and found that *importing* Twisted overrode how logging is done.  My
> import warnings (a 2.2 extension used under 2.3) were going into
> never-never land.  I tracked that down and I believe it's fixed in the
> current code.

I'm not an expert in this code, but twisted.python.log has been
reimplemented in 1.0.5, and presumably it's better ;)  

(Also, there's code in the sandbox that implements the old log API using the
logging module of Python 2.3; perhaps that will be updated for our new log
code at some point).

> In general, I got the feeling that Twisted does its own thing.  That is,
> it uses its own names, it override at least some ways Python does
> things, and I noticed it tried to fake a "sychronized" keyword for
> some of the logging, rather than use a more Pythonic Queue.  It
> even has its own VMS-style command-arg parsing (including
> the automatic prefix expansion I don't like) rather than use Python's.

Python 2.3 isn't released yet, and I find writing a
twisted.python.options.Usage subclass with some attributes far nicer and
more readable than writing the boilerplate code that getopt requires.  I
think in this case having our own command-line parser was reasonable --
Twisted originally supported 1.5.2, after all, and its users certainly
didn't have an optparse module :)

I'm not sure what you're referring to with "automatic prefix expansion I
don't like"?

(There's also code in the sandbox to implement twisted.python.options using
optparse.)

> Admittedly, the logging code I looked at is considered old, so perhaps
> feelings have changed, but there was talk of writing a new logging facility
> because the one to be included in Python 2.3 wasn't good enough,
> which again suggests a tendency towards idiosyncratic code.

Agreed.  I've heard both sides of this argument, but I don't know enough to
be able to comment usefully on it.  One big problem is that Twisted supports
2.2.0, and so requiring the 2.3 logging package would burden users with an
extra dependency (ditto optparse/Optik).

> That doesn't mean I won't use it, I just suggest that this tendency to
> write code with non-standard behaviour (wrt "Pythonic" code) makes
> it harder for some people to use Twisted.

We've certainly reimplemented one or two (or ten...) wheels here and there.
Another big one you haven't mentioned is we have our own XML parser and DOM
implementation.  I've even seen the phrase "Twisted: The Batteries Python
Forgot" used in jest.

On the other hand, asyncore already did asynchronous networking for Python,
and we've reimplemented that too -- but I think the result is something much
better than asyncore.  If we've reinvented something, there will be a reason
for it.  But as you point out, it can make life harder for our users.  

> > [1] When I started using Twisted, I had to learn pretty much everything by
> >     asking on IRC; even the "Writing Servers" document didn't exist.
> 
> I've done IRC now 3 times, all for Twisted.  IRC just doesn't really fit
> my mind, which has been warped by Usenet-style interactions.

I know how you feel -- some people want me to use some form of instant
messaging (in addition to IRC!), and it just doesn't quite feel right to me
:)

-Andrew.






More information about the Python-list mailing list