08:53 <discord_afpy> <Andy K (boss dreamer ou pas)> Salut
13:15 <discord_afpy> <guyzmal> @entwanne - hm… mais en l'occurence, ça ne permet pas de faire récupérer le type « type retouné par la fonction `lib_func` » et de l'utiliser dans `my_func()`. En vrai, je ne vois pas trop ce que le wrapper ajoute d'intéressant, car finalement `obj` avec ou sans le wrapper aura bien le type retourné par `lib_func` via l'inférence.
13:15 <discord_afpy> <guyzmal>
13:15 <discord_afpy> <guyzmal> Par contre si je crée une fonction `my_func(foo: XXX)` comment puis-je lui donner le type de retour de `my_func`?
13:15 <discord_afpy> <guyzmal>
13:15 <discord_afpy> <guyzmal> En suivant la même logique, je pourrais construire une `class my_func` à qui je donne `my_func` en constructeur, et donc `?call?` prend un argument de type `T`.
13:15 <discord_afpy> <guyzmal>
13:15 <discord_afpy> <guyzmal> Mais clairement c'est méga compliqué, ça augmente la complexité en runtime pour résoudre un problème static, donc build time
13:15 <discord_afpy> <guyzmal> pour illustrer : https://wyz.fr/5K-BD
13:18 <discord_afpy> <guyzmal> en gros en typescript, ce truc s'écrit comme ça :
13:18 <discord_afpy> <guyzmal>
13:18 <discord_afpy> <guyzmal> ```
13:18 <discord_afpy> <guyzmal> import { lib_func } from "lib"
13:18 <discord_afpy> <guyzmal>
13:18 <discord_afpy> <guyzmal> function my_func(foo: ReturnType<lib_func>) {
13:18 <discord_afpy> <guyzmal> print(`I'm doing something with ${foo} of type {typeof foo}`)
13:18 <discord_afpy> <guyzmal> }
13:18 <discord_afpy> <guyzmal> ```
13:20 <discord_afpy> <guyzmal> (autant le javascript ça reste et restera 🤢 , autant le travail fait par les équipes de typescript sur la surcouche de typage est extraordinaire !)
13:35 <entwanne> C'est pour ça que je t'invitais à repenser le problème, à ma connaissance il n'y a pas moyen d'exprimer un type relatif à un autre en dehors des génériques. Le wrapper que je montre n'ajoute rien d'intéressant, c'était juste pour montrer comment on pouvait faire correspondre les types T et Callable[..., T]
13:36 <entwanne> En pratique je ne vois pas vraiment de cas d'usage où tu veuilles exprimer "x est du même type que y" : soit tu connais le type (ou un protocole adéquat) et tu le définis tel quel statiquement, soit tu ne le connais pas et dans ce cas autant laisser faire l'inférence sans annotation
13:49 <discord_afpy> <guyzmal> beh en soit, l'alternative c'est que toutes les libs publient leurs types correctement ☺
13:58 <entwanne> oui, et quand ce n'est pas le cas tu peux ajouter ton propre adaptateur / protocole, ça évite de trop dépendre des aspects internes de la lib (est-ce que telle fonction renvoie toujours exactement le même type, etc.)
20:18 <discord_afpy> <guyzmal> 💡 en lisant de la doc sur le sujet, je suis tombé sur cet article, qui explique pas mal de choses :
20:18 <discord_afpy> <guyzmal>
20:18 <discord_afpy> <guyzmal> https://medium.com/@Pilot-EPD-Blog/typescript-for-pythonistas-f90bbb297f0a
20:23 <discord_afpy> <guyzmal> il dit clairement dans l'article « However, TypeScript also packs a number of concepts that can’t be easily expressed in mypy » (https://arc.net/l/quote/uxqxiarh)
21:02 <discord_afpy> <fred.et.rick> la partie sur l’inférence de `x = "hi"` et un peu bizarre. l’autrice compare une variable avec une constante, mais si on compare des variables ```js
21:02 <discord_afpy> <fred.et.rick> let x = "hi"
21:02 <discord_afpy> <fred.et.rick> ``` là typescript infère que x est de type string, pas de type literal. et si on compare des constantes, ```py
21:02 <discord_afpy> <fred.et.rick> x: Final = "hi"
21:02 <discord_afpy> <fred.et.rick> ``` mypy infère bien que x est de type `Literal["hi"]`