Istnieje wiele różnych aspektów Twisted, które mogą Ci się spodobać.
Twisted zawiera wiele implementacji protokołów, co oznacza, że najprawdopodobniej będzie API, którego możesz użyć do komunikacji z jakimś zdalnym systemem (w większości przypadków klientem lub serwerem) - czy to HTTP , FTP , SMTP, POP3, IMAP4 , DNS , IRC, MSN, OSCAR, XMPP / Jabber , telnet, SSH , SSL, NNTP lub jeden z naprawdę niejasnych protokołów, takich jak Finger lub ident, lub jeden z protokołów budowania protokołów niższego poziomu, takich jak łańcuchy sieciowe DJB , proste protokoły zorientowane liniowo , a nawet jeden z niestandardowych protokołów Twisted, takich jak Perspective Broker (PB) lubAsynchronous Messaging Protocol (AMP) .
Kolejną fajną rzeczą dotyczącą Twisted jest to, że oprócz tych niskopoziomowych implementacji protokołów często znajdziesz abstrakcję, która jest nieco łatwiejsza w użyciu. Na przykład, pisząc serwer HTTP, Twisted Web dostarcza abstrakcji „Zasobów”, która pozwala konstruować hierarchie adresów URL z obiektów Pythona w celu określenia sposobu odpowiadania na żądania.
Wszystko to jest powiązane ze współpracującymi API, głównie ze względu na to, że żadna z tych funkcjonalności nie jest implementowana poprzez blokowanie w sieci, więc nie musisz uruchamiać wątku dla każdej operacji, którą chcesz wykonać . Przyczynia się to do skalowalności, którą ludzie często przypisują Twisted (chociaż jest to rodzaj skalowalności, który obejmuje tylko jeden komputer, a nie rodzaj skalowalności, która pozwala aplikacji urosnąć do wykorzystania całego klastra hostów), ponieważ Twisted może obsłużyć tysiące połączeń w jednym wątku, który zwykle działa lepiej niż tysiące wątków, każdy dla jednego połączenia.
Unikanie wątków jest również korzystne przy testowaniu i debugowaniu (a tym samym ogólnej niezawodności). Ponieważ w typowym programie opartym na Twisted nie ma wyprzedzającego przełączania kontekstu, generalnie nie musisz się martwić o blokowanie. Warunki wyścigu, które zależą od kolejności zachodzących różnych zdarzeń sieciowych, można łatwo przetestować jednostkowo, symulując te zdarzenia sieciowe (podczas gdy symulacja przełączania kontekstu nie jest funkcją zapewnianą przez większość (jakichkolwiek?) Bibliotek wątków).
Twisted też bardzo, bardzo przejmuje się jakością . Więc będziesz rzadko znaleźć regresji w komunikacie Twisted, a większość z API po prostu działać, nawet jeśli nie są używane w zwykły sposób (bo staramy się testować wszystkie sposoby można z nich korzystać, a nie tylko wspólnym sposób). Jest to szczególnie prawdziwe dla całego kodu dodanego do Twisted (lub zmodyfikowanego) w ciągu ostatnich 3 lub 4 lat, ponieważ od tego czasu 100% pokrycia linii jest minimalnym wymogiem testowania.
Kolejną często pomijaną mocną stroną Twisted jest dziesięć lat odkrywania różnych dziwactw platformowych . Istnieje wiele nieudokumentowanych błędów gniazd na różnych platformach i naprawdę trudno jest dowiedzieć się, czy w ogóle istnieją, nie mówiąc już o ich naprawieniu. Twisted stopniowo obejmuje coraz więcej z nich i na tym etapie jest z tym całkiem dobrze. Młodsze projekty nie mają tego doświadczenia, więc brakuje im niejasnych trybów awarii, które prawdopodobnie przydarzą się tylko użytkownikom dowolnego projektu, który wydasz, a nie Ciebie.
Wszystko, co mówię, to, co uważam za najfajniejsze w Twisted, to to, że jest to dość nudna biblioteka, która pozwala mi zignorować wiele naprawdę nudnych problemów i po prostu skupić się na interesujących i zabawnych rzeczach. :)