Du coup que faire ? Pour migrer de Python2 vers Python3 ont été mis en place des outils et des best practices, ne serait-ce pas une solution que de faire de même pour ce nouveau problème.

Je verrais bien un projet expliquant comment faire en sorte qu’une bibliothèque synchrone soit compatible

– On considère une bibliothèque de basique utilisant les sockets python standard

– On présente comment abstraire les implémentations bas niveau

– On fourni des implémentations de base pour la version synchrone, asynchrone avec gevent et celle asynchrone avec asyncio

– On explique comment faire pour garder les choses compatible Python2/3 (notamment avec les “yield from” qui n’existent pas en python<3)

Je pense qu’une démo par l’exemple de cette forme fournirait une guideline très pratique, toutefois je reste dubitatif sur la faisabilité même d’une bibliothèque compatible synchrone/asyncio vu que le second oblige à penser toute sa pile d’appel avec des “async”…

Si je prend l’exemple de http://zeromq.org/ . C’est une lib qui repose sur un protocole qui fait que zeromq ne parle qu’avec zeromq.

Ce protocole n’a été extrait que récemment et il me semble que c’est beta : http://zmtp.org/

Qu’est ce que ça veut dire : dépendre de l’implémentation ? Quel contre exemple positif à donner ?

Je crois sans te vexer Sam que tu confond ou plutôt que tu n’explicite pas le flou qu’il existe entre :

Paradigme de programmation
Théorie informatiques pure (Un truc con) (1)
Théorie informatiques des OS (pipe en Shell) (2)
Concepts first class (goroutine en Go, Erlang, monade Haskell) dans un langage

(Pour ZeroMQ, le fait qu’elle est codé en C++ rend le bindings simple
alors qu’une lib python dépend du langage et est difficile à inclure, intégrer dans un autre ou pire un sous langage.

designs patterns
bibliothèques
frameworks
toolkit

(1) (2) Je pose la question à 1 000 000 de dollars en jouant au candide. Comment cela ce fait il que les pipes shell bash n’existe que shell et pas dans tout les langages ? C’est bizarre, tous les langages possède des fonctions (subroutine) ?

Pourquoi ?

Mais, ceci n’engage que mon expérience, les avantages que tu y vois sont, de mon point de vue, fortement contrebalancés par les coûts de maintenance et le ticket d’entrée des contributeurs.

3615 my life pour illustrer: Exemple qui m’est arrivé au début que j’utilisais AsyncIO, outre Crossbar qui est multi async framework, il y a également Obulus, un binding Asterisk écrit par Antoine Pitrou (coucou Antoine): https://bitbucket.org/optiflowsrd/obelus

Antoine a fait un gros travail d’abstraction pour justement supporter différents frameworks async.

Je suis surement très bête, mais j’ai eu beaucoup de mal à comprendre comment ça fonctionnait en dessous pour pouvoir l’enrichir.

Pour finir, j’ai pris Panoramisk, https://github.com/gawel/panoramisk qui sur le papier était moins avancé à l’époque mais où j’arrivais à rajouter des fonctionnalités mais surtout à être autonome pour debugger par moi-même.

Autant je suis partisan pour lire du code d’implémentation d’autres librairies pour récupérer des idées, autant vouloir une abstraction dans tous les sens me paraît augmenter les coûts de maintenance et d’ajout de fonctionnalités de manière exponentielle.

L’async est déjà assez compliqué à gérer par lui-même, vouloir en plus être multi async framework dont chacun n’a pas forcément la même stratégie de scheduling, c’est un peu comme vouloir être ami avec tout le monde: à un moment, il faut faire des choix sinon on risque de manquer de cohérence ;-)

Concrètement, quand tu vas avoir un bug en production dans la couche d’abstraction, vas-tu être capable de corriger rapidement ? Chaque librairie que tu rajoutes avec cette surcouche, es-tu capable de plonger dedans au prochain problème ?

Si oui, tant mieux, mais quelle est la probalité que d’autres vont également y arriver ?

Sans parler du fait que tous les frameworks async ne sont pas égaux, et donc ça va être un sous ensemble qui sera utilisé, un peu comme les ORMs avec les DBs.

Mais après, vous faites comme vous voulez les gens, c’est votre temps libre/votre stress à gérer quand il y aura un problème ;-)

tu auras quelque chose de simple, + ça sera facile d’accès aux développeurs.

Pour moi, les approches à la Java/Zope avec beaucoup d’abstractions me semblent avoir déjà montré par le passé que cela n’est pas la silver bullet pour faire du développement.

Un des design patterns le plus recommandé et de créer un maximum de classes abstraites / interfaces et laisser à la fin l’implémentation.

Le hic dans python c’est qu’il n’y pas de classes abstraites et encore moins d’interfaces.

Forcément le dèv s’attaque directement à l’implémentation.

Autre point, faire du design avant d’implémenter, c’est après quelques années de galères à découpler dans tous les sens les travaux des autres qu’on en voit l’intérêt.

Donc oui, faut de l’expérience + pas mal de connaissances théoriques sur les design patterns => ça limite le nombre de contributeurs.

Après, comme tu le dis si bien, faut pas tomber dans le piège du design pour le design à la zope mais en général, il est facile d’identifier ce qui est spécifique au générique.