Twisted est un cadriciel (framework) de développement asynchrone pour Python. Le projet est ancien (plus de 11 ans), stable, largement utilisé, activement développé et dispose d'un nombre impressionnant de fonctionnalités (serveur/client HTTP, IMAP, SSH, FTP, IRC, NNTP, support de TCP, UDP, SSL/TLS, Multicast, etc). Plusieurs projets gravitent autour, comme Wokkel qui améliore grandement la prise en charge déjà existante de XMPP, ou Crochet qui permet d'utiliser Twisted depuis des programmes bloquants. La suite de la dépêche décrit les nouveautés de la fraîche 14.0.0.
NdA : Merci à palm123 et BAud pour leur relecture et leurs corrections.
Nouveautés
Les nouveautés sont, selon une traduction de l'annonce officielle.
Twisted Positioning vient d'arriver dans Twisted ! Il arrive déjà prêt pour communiquer avec les matériels GPS communs et va remplacer « twisted.protocols.gps »
Beaucoup d'améliorations pour SSL/TLS, avec entre autres l'utilisation de ECDHE (les courbes elliptiques), la vérification des identités des services TLS (avec service_identity sur PyPI), un jeu d'algorithmes de chiffrement par défaut plus solide, un renforcement contre des attaques comme CRIME. Un serveur web Twisted avec pyOpenSSL 0.14 est capable d'obtenir un A dans les tests SSL de « Qualys SSL Labs » par défaut et un A+ avec quelques ajustement mineurs dans l'application. Un « agent » Twisted peut aussi, désormais, vérifier des noms de domaine HTTPS
Des améliorations Python 3 (voir ci-dessous), incluant la possibilité d'installer les modules portés via « pip install »
Dans Twisted Pair, la gestion de TUN/TAP a été réécrite, avec une documentation et une couverture de tests complète.
De grandes améliorations dans la documentation, avec plus d'informations sur l'API de Twisted Mail et Twisted Names, une documentation plus verbeuse pour Twisted Names et une migration sur Sphinx.
Fin de la prise en compte de pyOpenSSL < 0.10 et de Windows XP.
Est-ce que Twisted est condamné à disparaître avec async I/O et Python 3 ?
Glyph, un des développeurs principaux de Twisted, explique dans un long billet pourquoi l'arrivée de Tulip/Async I/O n'est pas l'annonce de la mort de Twisted et, qu'au contraire, c'est une bonne chose pour Twisted (et réciproquement). Pour résumer les grandes lignes, Glyph indique que comparer Twisted à Async I/O, c'est équivalent à comparer OpenOffice à Linux.
En effet, Async I/O implémente principalement une couche de transport et une API d'une boucle événements. Il implémente aussi un ordonnanceur de coroutines. À cela s'ajoutent quelques bibliothèques expérimentales et modules d'extensions comme un serveur et un client HTTP événementiels.
Pour simplifier, Glyph indique que Async I/O est comparable à un noyau pour la programmation événementielle et quelques applications commencent à en tirer parti.
Twisted implémente également tout cela (les coroutines sous la forme d'inlineCallbacks). Twisted implémente aussi un serveur événementiel prêt pour la mise en production, incluant son propre système de modèles événementiel, avec des ajouts tiers (cf billet originel pour une liste), un client et un serveur SSH (qui a été ou est utilisé sur Launchpad), un système de transmission de messages fait pour être facile à implémenter, permettant de développer très facilement un protocole personnalisé.
Twisted est aussi un serveur de messagerie qui peut se déployer en une seule commande de terminal, un kit de construction pour des robots IRC, une implémentation client/serveur de XMPP et de certaines de ses extensions (en particulier avec Wokkel), un serveur et un client DNS, une API d'identification ou un système de transport : il est, par exemple, possible de faire tourner un service à travers TOR avec un argument en ligne de commande sans modifier son code.
Twisted permet également de gérer les données de géolocalisation ou de s'intégrer facilement avec les bibliothèques d'interfaces les plus courantes. Et la liste n'est pas finie…
Glyph ajoute que bien sûr la communauté naissante de Async I/O va petit à petit rattraper voire dépasser certains de ces points, qu'il va y avoir de la duplication de code, etc. Mais que ce n'est pas une mauvaise chose, au contraire, et que le but est de pouvoir faire interagir facilement toutes ces choses (Tornado est aussi cité).
Twisted ne reste pas bloqué à Python 2 et il y a un travail en cours pour le port sur Python 3. Mais Python 2 est encore bien présent et même majoritaire. Twisted est utilisé dans de nombreux projets en production et l'équipe a des ressources limitées, aussi il est essentiel de garder la compatibilité ascendante, d'autant plus que cela permet d'utiliser Twisted avec pypy et de bénéficier d'importants gains en performances.
Petit à petit les choses vont évoluer, l'écosystème Async I/O va progresser, le support de Python 3 dans Twisted va s'améliorer, il faut espérer que tout ce beau monde puisse interagir facilement, et qu'on puisse choisir, voire mixer la puissance de ces outils.
Cette dépêche reprend et résume librement le billet de glyph, la lecture du billet originel est fortement recommandée pour les anglophones.
Aller plus loin
- Annonce officielle de Twisted 14.0.0 (144 clics)
- Le report de notre mort, le billet de Glyph (91 clics)
- Site officiel (260 clics)
# asyncio et Python 2 : Trollius !
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Comme dit dans l'article de Glyph, il existe un backport d'asyncio pour Python 2 :
http://trollius.readthedocs.org/
C'est "presque" pareil qu'asyncio, la principale différence est la syntaxe de coroutines (yield From(…) vs yield from …). Il est possible d'écrire du code compatible Trollius, Tulip (Python 3.3) et asyncio (Python 3.4, 3.5) :
http://trollius.readthedocs.org/#write-code-working-on-trollius-and-tulip
Effectivement, les projets écrits pour asyncio sont jeunes. C'est normal, asyncio n'est stable que depuis quelques mois. Pour en avoir la liste :
https://code.google.com/p/tulip/wiki/ThirdParty
Voir aussi ce site qui liste les ressources asyncio :
http://asyncio.org/
Ma principale critique de Twisted est qu'il est facile de mal utiliser le système de callback et d'écrire du code qui ne sera pas exécuté séquentiellement (car les callbacks ne sont pas bien chaînés). Écrire du code par callback est verbeux, répétitif et difficile. Je ne parle même pas du débogage :-( @inlineCallbacks rend l'écriture de code Twisted plus aisé, mais ce n'est pas utilisé pour tout et ça reste un peu du bricolage dans Twisted.
[^] # Re: asyncio et Python 2 : Trollius !
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
l'inconvénient principal des inlineCallbacks est une perte de performances énorme dans pypy (de ce que j'en ai lu, je n'utilise pas -encore ?- pypy).
Pour l'écriture et le débogage, l'écriture est en effet un peu difficile, c'est une habitude à prendre, par contre pour le débogage je n'ai pas trop de soucis, surtout grâce à leur système qui permet de tracer l'origine d'un Deferred en mode debug.
Bon en tout cas faut voir les évolutions de tout ça, mais si ça peut effectivement interagir comme promis, l'avenir devrait être très intéressant.
# Coro
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est du Perl mais c'est toujours intéressant me semble t-il de voir ce que font les voisins… Bref, en Perl, il y a un super environnement qui permet de faire ce chose de chose de manière non verbeuse (pas comme POE par exemple) : Coro. Je l'utilise dans quelques scripts et c'est vraiment un bonheur de simplicité et d'efficacité.
http://search.cpan.org/~mlehmann/Coro-6.37/Coro.pm
http://search.cpan.org/~mlehmann/Coro-6.37/Coro/Intro.pod
# SMTP
Posté par steph1978 . Évalué à 2.
Est ce que cela permet d'implémenter un serveur SMTP ?
J'aimerai déployer mon propre serveur SMTP mais avec un comportement custom et je ne sais pas trop comme m'y attaquer. En python ça m'aurait plu.
[^] # Re: SMTP
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Oui tout à fait:
https://twistedmatrix.com/trac/wiki/TwistedMail
https://twistedmatrix.com/documents/current/_downloads/emailserver.tac
http://pepijndevos.nl/twsited-smtp-server-with-authentication/index.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.