Existem muitos aspectos diferentes do Twisted que você pode achar interessantes.
Twisted inclui muitas e muitas implementações de protocolo, o que significa que muito provavelmente haverá uma API que você pode usar para se comunicar com algum sistema remoto (cliente ou servidor na maioria dos casos) - seja HTTP , FTP , SMTP, POP3, IMAP4 , DNS , IRC, MSN, OSCAR, XMPP / Jabber , telnet, SSH , SSL, NNTP , ou um dos protocolos realmente obscuros como Finger ou ident, ou um dos protocolos de construção de protocolo de nível inferior como DJB's netstrings , simples protocolos orientados a linha , ou mesmo um dos protocolos personalizados da Twisted como Perspective Broker (PB) ouProtocolo de mensagens assíncronas (AMP) .
Outra coisa legal sobre o Twisted é que além dessas implementações de protocolo de baixo nível, você geralmente encontrará uma abstração que é um pouco mais fácil de usar. Por exemplo, ao escrever um servidor HTTP, Twisted Web fornece uma abstração de "Recurso" que permite construir hierarquias de URL a partir de objetos Python para definir como as solicitações serão respondidas.
Tudo isso está vinculado a APIs cooperantes, principalmente devido ao fato de que nenhuma dessas funcionalidades é implementada por bloqueio na rede, portanto, você não precisa iniciar um thread para cada operação que deseja fazer . Isso contribui para a escalabilidade que as pessoas muitas vezes atribuem ao Twisted (embora seja o tipo de escalabilidade que envolve apenas um único computador, não o tipo de escalabilidade que permite que seu aplicativo cresça para usar um cluster inteiro de hosts) porque o Twisted pode lidar com milhares de conexões em um único encadeamento, o que tende a funcionar melhor do que ter milhares de encadeamentos, cada um para uma única conexão.
Evitar encadeamento também é benéfico para teste e depuração (e, portanto, confiabilidade em geral). Como não há troca de contexto preventiva em um programa baseado em Twisted típico, você geralmente não precisa se preocupar com o bloqueio. As condições de corrida que dependem da ordem dos diferentes eventos de rede que acontecem podem ser facilmente testadas na unidade simulando esses eventos de rede (enquanto a simulação de uma troca de contexto não é um recurso fornecido pela maioria (qualquer?) Biblioteca de encadeamento).
A Twisted também se preocupa muito, muito com a qualidade . Então, você raramente encontrará regressões em uma versão do Twisted, e a maioria das APIs simplesmente funcionam, mesmo se você não as estiver usando da maneira comum (porque tentamos testar todas as maneiras de usá-las, não apenas as comuns maneira). Isso é particularmente verdadeiro para todo o código adicionado ao Twisted (ou modificado) nos últimos 3 ou 4 anos, uma vez que 100% de cobertura de linha tem sido um requisito mínimo de teste desde então.
Outro ponto forte frequentemente esquecido do Twisted são seus dez anos descobrindo diferentes peculiaridades da plataforma . Existem muitos erros de soquete não documentados em diferentes plataformas e é realmente difícil saber que eles existem, quanto mais lidar com eles. O Twisted gradualmente cobriu mais e mais deles, e é muito bom nisso neste ponto. Projetos mais jovens não têm essa experiência, então eles perdem modos de falha obscuros que provavelmente só acontecerão com os usuários de qualquer projeto que você lançar, não com você.
Dito isso, o que eu acho mais legal no Twisted é que é uma biblioteca muito chata que me permite ignorar muitos problemas realmente chatos e me concentrar apenas nas coisas interessantes e divertidas. :)