[Twisted-Python] Getting Stories Straight (RPYs)

Moshe Zadka m at moshez.org
Tue Jun 24 02:13:28 EDT 2003

First, let me clarify: I never said "don't use listenTCP". I merely
said that using application.listenTCP(0,...) is a bad idea, and if you
want to listen on an arbitrary port, you should do it with an

Now, let me clarify the position about RPYs: The official line is
"your development must be orthogonal to your deployment". What this
means is that if you are developing a web application, it should be
a resource with children, and internal links. Some of the children
may use Woven, some may be resources manually using .write, etc. The
point is, the code should be in a Python module, or package, *outside*
the web tree. You will probably want to test your application as you
develop it. There are many ways to test, starting with dropping an
.rpy which looks like

from mypackage import toplevel
resource = toplevel.Resource(file="foo/bar", color="blue")

into a directory, and then running

% mktap web --path=/directory
% twistd -f web.tap

to writing a Python script like

from twisted.web import server
from twisted.internet import reactor
from mypackage import toplevel
    server.Site(toplevel.Resource(file="foo/bar", color="blue")))

Which one of these strategies you use is not terribly important, since
(and this is the important part) deployment is *orthogonal*. Later, when
you want users to actually *use* your code, you should worry about what
to do -- or rather, don't. Users may have widely different needs. Some
may want to run your code in a different process, so they'll use distributed
web. Some may be using the Debian package, and will drop in

% cat > /etc/local.d/99addmypackage.py
from mypackage import toplevel
default.putChild("mypackage", toplevel.Resource(file="foo/bar", color="blue"))

If you want to be friendly to your users, you can supply many examples
in your package, like the above .rpy and the Debian-package drop-in.
But the *ultimate* friendliness is to write a useful resource which does
not have deployment assumptions built in.

This is what itamar meant by "Twisted.Web is not PHP": since we have
a better tool for organizing code (Python modules and packages), use it.
In PHP, the only tool for organizing is web pages, which leads to silly
things like PHP pages full of functions that other pages import, etc.
etc. If you translate this wholesale into Python, you may assume the
correct way to do web development is to have many RPYs, all importing
some Python module. This is a *bad idea* -- it mashes deployment with
development, and makes sure your users will be *tied* to the file-system.

We respect you enough to assume you're using Twisted.Web to write non-trivial
applications. This means that you will eventually have the Twisted.Web Zen,
by the time you finish to write your application. Using itamar's methodology
insures that when you *do* have the Zen, you will have less of an itch to
throw it away and start anew because it is crap.

So, to sum up: We have .rpys because they are useful and necessary. But
using them incorrectly leads to horribly unmaintainable applications. The
best way to insure using them correctly is to not use them at all, until
you are on your *final* deployment stages. By then, the whole "An RPY must
be less than 10 lines" will be superfluous because you will not *have*
more than 10 lines to write.
Moshe Zadka -- http://moshez.org/
Buffy: I don't like you hanging out with someone that... short.
Riley: Yeah, a lot of young people nowadays are experimenting with shortness.
Agile Programming Language -- http://www.python.org/

More information about the Twisted-Python mailing list