Re: Rx

Quelque chose qui n'est visible qu'au runtime est invisible c'est quelque chose qui peut arriver implicitement et ça rend presque impossible une validation par revue du code

Les exceptions KeyboardInterrupt peuvent arriver à n'importe quelle moment dans ton programme Python et pourtant cela ne pose pas de soucis car on sait qu'il faut utiliser les block try/finally (ou les context manager font la même chose au final) pour gérer le nettoyage de ton code proprement. C'est pour cela que ce code est mauvais:

fd = open('foo', 'rw')
data = fd.read()
... # si une exception raise fd.close() ne sera pas appelé
fd.write(result)
fd.close()

et que celui-ci est bon:

with open('foo', 'rw') as fd:
 data = fd.read()
 ... # quoi qu'il arrive le with s'occupera de fermer fd
 fd.write(result)

C'est exactement la même chose avec trio, sauf que tu te prends une exception trio.Cancelled au lieu d'une KeyboardInterrupt (et ça te coute rien de plus puisque t'es déjà obligé de gérer le cas KeyboardInterrupt)

Pourquoi ne pas gérer ça dans une forme de machine à état ?

En effet si le language le permet c'est très bien de le faire. Toutefois ce n'est pas le cas de Python donc il faut soit recréer un framework pour le faire, soit se taper le code à la main (et là autant dire qu'on a perdu)... soit tout simplement utiliser un paradigme adapté à ce langage.

« let it crash » c'est particulier. Ça dépend de ce que tu fais comme application.

Ça dépend surtout du niveau de granularité que tu as mis en place. Si tu crashes tout appli et la relance de zéro c'est sûr que ça ne marchera pas de masse, mais il est tout à fait possible de ne relancer qu'une partie (exemple typique: un serveur web qui ne se relance pas à chaque erreur 500 qui lui arrive, au exemple: dans une appli mobile si le service responsable de multiplexer les requêtes vers ton backend crash tu le redémarres et tu as juste à signifier aux traitements qui était en attente de ce service qu'il y a eu une déconnexion)

Interrompre son taf c'est déjà modifier son contexte, le fait de sortir manu military des blocs de codes détruits un tas de variables,...

D'un autre côté son taf a déjà été interrompu par l'erreur à l'origine de l'exception, maintenant c'est juste question de retourner dans un état stable (et donc d'arrêter/relancer tout ce qui a besoin de l'être).

Au final j'ai l'impression que tu opposes programmation par message avec ce que propose trio.
De mon point trio est une brique de plus bas niveau qui te donne des outils de qualité (cad qui te font gagner du temps et qui te pousse à faire du code propre) pour faire de l'asynchrone, à charge pour toi de l'utiliser pour faire du passage de messages ou bien du partage de ressources en fonction de ton besoin.