hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I have a twisted TCP server to listens to client, processes requests, do
mysql database operations if needed (using adbapi Connection pool) and
return the result. Before deploying this in production, I want to know
right way to configure the server.
Since twisted is single threaded, how can I leverage multiple cores of my
production machine (which has 6 cores and 16 GB RAM) ?
One approach that I thought of was to start multiple instances of twisted
server on different ports. This would help in using the other cores as
well. What do you guys suggest ?
I would like to announce txZMQ, ZeroMQ bindings for Twisted. txZMQ is based
on pyzmq and requires recent ØMQ version (>=2.1).
txZMQ uses ØMQ APIs to get file descriptor that is used to signal pending
actions from ØMQ library IO thread running in separate thread. txZMQ should
be usable with any Twisted reactor.
* The socket library that acts as a concurrency framework.
* Carries messages across inproc, IPC, TCP, and multicast.
* Connect N-to-N via fanout, pubsub, pipeline, request-reply.
* Fast enough for clustered products and supercomputing.
* Asynch I/O for scalable multicore message-passing apps.
Bridging ØMQ and Twisted makes a nice match: fast simple messaging between
Twisted instances solving complex problems :)
* PyPi: http://pypi.python.org/pypi/txZMQ/
* Source code: https://github.com/smira/pyzmq
* pyzmq: http://pypi.python.org/pypi/pyzmq
* ØMQ: http://www.zeromq.org/
Qik Web Team Lead
Right now apilinks.py is located in Twisted
at docs/_extensions/apilinks.py, but a copy can also be found in pydoctor
While reporting a bug for apilinks.py in Twisted I was ask to send the
patch upstream in pydoctor 
During the review of the patch in pydoctor, pydoctor's maintainer agreed
that there should be a single copy of this file but don't know what's
involved in achieving that. 
Can someone involved in using apilinks.py in Twisted provide some feedback
regarding distribution of apilinks.py file?
Apologies for the cross-post, but this is a "which framework" question
so seemed the most constructive way. Not interested in religious
debates, just trying to pick the best tool for the job and didn't get
much of a useful response from python-list...
So, I see python now has a plethora of async frameworks and I need to
try and pick one to use from:
From my side, I'm looking to experimentally build a network testing
tool that will need to speak a fair few protocols, both classic tcp and
multicast-based, and have a web api living on top of it that most likely
will have a websocket for pumping data to the browser. It'll also need
to write out JUnit-compatible xml results, but that's like the easiest
I'd like to be able to serve the rest of the web api using a pyramid
wsgi app if possible, and I'd like to be able to write the things that
process requests in and validation out in a synchronous fashion, most
likely spinning off a thread for each one.
The protocols are all financial (do we really not have a pure-python FIX
library?!) but none are likely to have existing python implementations.
How should I pick between the options? What would people recommend and why?
Simplistix - Content Management, Batch Processing & Python Consulting
I'm not sure if we've written this down anywhere official-looking, but if you're writing new tests in Twisted today, there is no reason that they should ever return a Deferred.
Returning Deferreds from tests in Trial is useful _only_ for writing integration tests that rely on external services which cannot be reasonably implemented or faked within Twisted itself. In some applications, this is an unfortunate fact of life, which is why Trial provides the feature and will continue to provide it. For example, writing unit tests for a database-backed application which depends intimately upon stored procedures would require altogether too much mocking and it's useful to be able to simply call out to the real database within tests. However, this is assuming that you can run your database locally in isolation as part of your test suite, and there is absolutely no non-determinism present in the application's communications with its database.
However, there is nothing like this within Twisted itself. In extreme cases where you actually need to test real platform interactions, you can instantiate a reactor for your test and iterate it as the ReactorBuilder tests do, but in any case where you're testing a client/server interaction, parsing bytes, etc, you can use twisted.test.proto_helpers or twisted.test.iosim. In the branch I'm working on right now I'm moving some more general testing utilities from individual tests over to twisted.test.ssl_helpers as well, so it should be easy to test any TLS interactions you might have as well. (Note, these are for testing within Twisted only right now, at some point we need to clean up all the generally-useful things in twisted.test, including proto_helpers, put them in a module outside of *.test...)
To sum up: there is absolutely no reason whatsoever to ever use loopbackAsync, please don't ever use it in a new test.