Hay muchos aspectos diferentes de Twisted que pueden resultar interesantes.
Twisted incluye montones y montones de implementaciones de protocolos, lo que significa que lo más probable es que haya una API que pueda usar para hablar con algún sistema remoto (ya sea cliente o servidor en la mayoría de los casos), ya sea HTTP , FTP , SMTP, POP3, IMAP4 , DNS , IRC, MSN, OSCAR, XMPP / Jabber , telnet, SSH , SSL, NNTP o uno de los protocolos realmente oscuros como Finger, o ident, o uno de los protocolos de construcción de protocolos de nivel inferior como las cadenas de red de DJB , simple protocolos orientados a la línea , o incluso uno de los protocolos personalizados de Twisted como Perspective Broker (PB) oProtocolo de mensajería asincrónica (AMP) .
Otra cosa interesante de Twisted es que además de estas implementaciones de protocolo de bajo nivel, a menudo encontrarás una abstracción que es algo más fácil de usar. Por ejemplo, al escribir un servidor HTTP, Twisted Web proporciona una abstracción de "Recurso" que le permite construir jerarquías de URL a partir de objetos Python para definir cómo se responderán las solicitudes.
Todo esto está vinculado con las API cooperantes, principalmente debido al hecho de que ninguna de esta funcionalidad se implementa mediante el bloqueo en la red, por lo que no es necesario iniciar un hilo para cada operación que desee realizar . Esto contribuye a la escalabilidad que la gente atribuye a Twisted (aunque es el tipo de escalabilidad que solo involucra una sola computadora, no el tipo de escalabilidad que permite que su aplicación crezca para usar un grupo completo de hosts) porque Twisted puede manejar miles de conexiones en un solo hilo, que tiende a funcionar mejor que tener miles de hilos, cada uno para una sola conexión.
Evitar los subprocesos también es beneficioso para las pruebas y la depuración (y, por tanto, la fiabilidad en general). Dado que no existe un cambio de contexto preventivo en un programa típico basado en Twisted, generalmente no necesita preocuparse por el bloqueo. Las condiciones de carrera que dependen del orden en que ocurren los diferentes eventos de red pueden probarse fácilmente mediante la simulación de esos eventos de red (mientras que la simulación de un cambio de contexto no es una característica proporcionada por la mayoría de las bibliotecas de subprocesos (¿alguna?)).
Twisted también se preocupa mucho por la calidad . Por lo tanto, rara vez encontrará regresiones en una versión Twisted, y la mayoría de las API simplemente funcionan, incluso si no las está usando de la manera común (porque intentamos probar todas las formas en que las puede usar, no solo las comunes camino). Esto es particularmente cierto para todo el código agregado a Twisted (o modificado) en los últimos 3 o 4 años, ya que la cobertura de línea del 100% ha sido un requisito mínimo de prueba desde entonces.
Otro punto fuerte de Twisted que a menudo se pasa por alto son sus diez años de descubrir diferentes peculiaridades de la plataforma . Hay muchos errores de socket indocumentados en diferentes plataformas y es realmente difícil saber que existen, y mucho menos manejarlos. Twisted ha cubierto gradualmente más y más de estos, y es bastante bueno en este momento. Los proyectos más jóvenes no tienen esta experiencia, por lo que pierden los modos de falla oscuros que probablemente solo les sucederán a los usuarios de cualquier proyecto que publique, no a usted.
Dicho todo esto, lo que me parece más genial de Twisted es que es una biblioteca bastante aburrida que me permite ignorar muchos problemas realmente aburridos y concentrarme en las cosas interesantes y divertidas. :)