Hi, While looking at the code for the default SelectReactor I noticed that the selectables are stored in the form {object : 1, ...}. Is there any particular reason they're not stored in the format: { fd : object, ...}? A couple I can think of are that duplicate file-descriptors would cause problems (which they currently most likely would anyway) and objects which return different values from fileno based on context would no longer work correctly -- are either of these use-cases valid? The reason i'm bringing this up is because since 2.3 (I think) calls to socket.fileno are wrapped in a python function (as defined in socket.py) which I assume, when called in a tight loop over a large number of objects may result in a bottleneck (I certainly remember profiling code in the past where this was the case). This could be alleviated by passing a sequence of integers to select instead of the connection objects themselves. It could be that i'm missing something, or it could also be that this has never come up because until a short time ago socket.fileno was, of course, a C function :-). Another thing to think about for the future is that on September 10 selectmodule.c was changed so that select.select now supports any sequence. Currently SelectReactor makes a list from the readers and writers dictionary (calling dict.keys()) every iteration -- of course this is likely to remain the same for a while considering the need for backwards compatibility and i'm not even sure if the patch has been backported to 2.3 yet (unlikely since my 2.3.2 is dated Oct 6 and it does not exhibit this behaviour). Still, it's interesting to note for the future. Cheers, Sam.