To begin with, I want to describe in a bit more detail how I'm imagining the system to work.
There will be one main executable file, server.py. It will output only debug messages. To play the game, a client must use Telnet* to connect to the machine running game.py --server.
* I might not use Telnet, and instead write more Python to handle line sending and receiving using Twisted. This will yield greater flexibility, notably the ability to change the prompt to something better-looking. However, Twisted is a good way to test our server for now.
Each new client will spawn a new game thread, and later in development will have the opportunity to load state from a database on the server. This will be implemented with Twisted and (likely) a combination of JSON and cPickle - the user will enter a username (and maybe password), which will be hashed and looked up in the database or similar. The database will store the filename of the pickled 'state' dictionary or whatever needs to be saved.
For each of the server's client connections, it will use Twisted's event-driven model to handle new commands from the client. It will push these commands straight onto the queue, for the server's main game-loop thread to pop off and handle one-by-one.
I can store state using the Factory instance: I'll demo this by writing in a quick bit of code from the Twisted docs to store the number of concurrent connections, with the knowledge that it'll probably come in very handy later on.