07:29 <Mindiell> ça fait peur vos discussions, je n'utilise pas les types et je m'en sors très bien j'ai l'impression.
07:29 <Mindiell> Mais je dois pas avoir la même vision/connaissance :o)
07:40 <alain_afpy> Première publication libre de Multigit - https://linuxfr.org/news/premiere-publication-libre-de-multigit
08:09 <discord_afpy> <eyecontrol> Comme Typescript aussi
08:11 <discord_afpy> <eyecontrol> Après, la récursivité n'est jamais obligatoire, non ?
08:31 <entwanne> Les fontions récursives non, il y a toujours moyen de procéder manuellement avec une pile. Les types récursifs par contre ça permet de représenter correctement certaines structures de données (sinon il faut tout mettre à plat dans des listes/dictionnaires, mais ce n'est alors plus la même structure)
08:32 <entwanne> Mindiell: y a rien d'obligatoire ni de raison de "mieux s'en sortir", c'est juste une fonctionnalité en plus agréable à utiliser avec certains outils/frameworks
08:33 <entwanne> y a des gens qui n'utilisent pas asyncio et qui s'en sortent très bien, qui n'utilisent pas les threads et qui s'en sortent très bien, etc.
10:01 <discord_afpy> <saturn7694> ça fait gagner du temps sur le refactoring de gros projet. ça permet de voir ce qu'on a cassé en changeant un truc.
10:04 <discord_afpy> <fred.et.rick> Et surtout ça fait de la doc à pas cher et facile à lire
10:13 <alain_afpy> matin
10:13 <entwanne> ça fait éviter des bugs aussi
10:48 <debnet> J'ai pas encore le reflexe dans tous mes projets, mais si la codebase utilise d'origine le typage je m'y tiens.
10:48 <debnet> Après parfois quand je tombe sur des types compliqués, j'admets avoir la flemme de construire le type sous-jacent à base de T et autres symboles ésotériques.
11:29 <discord_afpy> <saturn7694> oui c'est le défaut du typage ça rend le code plus verbeux.
11:31 <discord_afpy> <saturn7694> > <entwanne> ça fait éviter des bugs aussi
11:31 <discord_afpy> <saturn7694> le refactoring génère souvent des bugs.
11:32 <discord_afpy> <duf59> Je suis plutôt pour le typage mais d'après mon expérience c'est difficile à maintenir sur un projet au delà d'une certaine complexité, surtout si on a des dépendances sans stubs, ou on se retrouve avec des # ignore un peu partout. Après ça dépend bien sur de l'effort et du temps qu'on est prêt à y mettre
11:33 <discord_afpy> <duf59> (je fais essentiellement des projets en Freelance, en général ca commence avec des type et au bout de quelques mois F* mypy 😵‍💫 )
11:36 <discord_afpy> <saturn7694> vaut mieux éviter les ignore si on commence à l'utiliser. après la perte de temps passé à maintenir le typage c'est du temps gagner pour la maintenance du code. mais il faut acquérir un peu d'expérience pour savoir définir efficacement les types dont on a besoin. ça reste du temps gagné sur le long terme.
11:38 <discord_afpy> <saturn7694> > (je fais essentiellement des projets en freelance, en général ca commence avec des types et au bout de quelques mois F* mypy 😵‍💫 )
11:38 <discord_afpy> <saturn7694> On peut garder mypy sur des fonctions critiques, mais d'expérience c'est plus compliqué à gérer aue l'avoir partout en fait.
11:41 <discord_afpy> <clytaemnestra> Hi everyone, just a reminder that it's the last chance to submit your proposal for EuroPython 2025! The Call for Proposals closes today at midnight UTC. 🙀 https://ep2025.europython.eu/programme/cfp
11:41 <discord_afpy> <clytaemnestra>
11:41 <discord_afpy> <clytaemnestra> We’re also searching for reviewers to help us shape the program! https://europython.eu/reviewers 🔥
11:42 <discord_afpy> <duf59> Et quand t'as tout tes types en place et mypy content, tu met à jour 2 dépendances et boom 20 erreurs mypy 😅
11:42 <discord_afpy> <duf59> Il n'y a que 2.7k issues sur leur github après tout :p
11:42 <discord_afpy> <saturn7694> c'est le but
11:43 <discord_afpy> <saturn7694> c'est des problèmes que tu n'arais pas vu sinon
11:55 <entwanne> saturn7694: Mais de façon générale, même hors refactoring, ça évite d'introduire certains bugs
11:58 <discord_afpy> <duf59> C'est surtout bourré de bugs, de cas particuliers, et de librairies qui ne gèrent pas les types, ou les gèrent en partie.
11:58 <discord_afpy> <duf59> A mon avis il faut garder en tête qu'on a un langage non typé sur lequel on ajoute une couche de typage quand même pas super clean.
11:58 <discord_afpy> <duf59> Pour avoir un typage à 100% autant utiliser un autre langage qui le supporte nativement non?
11:58 <discord_afpy> <duf59> Après moi je fais que du python donc pas trop le choix et je suis tout à fait d'accord sur le fait que ça rend le code plus fiable, mais je vois ça un peu comme ma couverture de test, 70-80% de c'est bien, au délà c'est rarement rentable (ps: je fais pas d'appli bancaire 😅 )
12:04 <entwanne> Ben Python est un langage typé (dynamiquement) de base, et supporte les annotations de type depuis un bon moment déjà
12:05 <entwanne> (nativement je voulais dire)
13:24 <discord_afpy> <fred.et.rick> pour le coup, ça ne m’arrive jamais
13:25 <discord_afpy> <fred.et.rick> le vrai truc chiant, c’est pas quand la dépendance n’a pas de stub, c’est quand y’a une erreur dans les stubs 😭
13:31 <discord_afpy> <fred.et.rick> > Après moi je fais que du python donc pas trop le choix et je suis tout à fait d'accord sur le fait que ça rend le code plus fiable, mais je vois ça un peu comme ma couverture de test, 70-80% de c'est bien, au délà c'est rarement rentable
13:31 <discord_afpy> <fred.et.rick> je suis pas trop d’accord sur les chiffres, mais globalement, oui, des fois faut pas passer 2h à essayer de typer un truc quand de toute façon, t’as une règle métier qui dit que ta donnée aura cette tête là et pas une autre, cast existe pour ça
13:40 <entwanne> Perso le truc qui m'embête c'est quand je ne peux pas plier le système de types pour définir ce dont j'ai besoin (par exemple un type qui se comporte comme NamedTuple mais qui n'en soit pas un, je finis par faire des `if TYPE_CHECKING` pour faire croire à mypy que le type est un alias de NamedTuple mais c'est pas satisfaisant)
13:51 <discord_afpy> <duf59> tu as les protocoles pour ça non?
13:58 <entwanne> C'est quoi le protocole correspondant au type NamedTuple ? Que les classes qui en héritent sont des tuples et définissent des noms d'attributs particuliers, mais je ne vois pas comment définir ça avec typing.Protocol (à moins d'avoir un protocole par classe héritant de NamedTuple, mais alors ça ne répond pas à l'usage)
14:11 <discord_afpy> <fred.et.rick> > par exemple un type qui se comporte comme NamedTuple mais qui n'en soit pas un
14:11 <discord_afpy> <fred.et.rick> tu aurais un exemple ? j’ai du mal à me représenter un cas d’usage
14:17 <entwanne> J'aurais cherché à définir quelque chose de similaire à dataclass_transform, mais pour des named tuples
14:18 <entwanne> Mon cas d'usage étant d'avoir mon propre type (parce que j'ai besoin de méthodes particulières et que je veux contrôler qu'il s'agit bien d'une sous-classe d'un type parent) qui soit sembable à l'usage aux named tuples
14:19 <entwanne> c'est assez facile à faire en Python, mais pas évident à typer
14:19 <entwanne> (de la même manière que dataclass_transform est d'une grande aide si on veut faire une classe qui ressemble à une dataclass — ie définisse des attributs qui peuvent être donnés en arguments au constructeur — sans en être une)
20:46 <discord_afpy> <fred.et.rick> > c'est assez facile à faire en Python, mais pas évident à typer
20:46 <discord_afpy> <fred.et.rick> ah oui, en effet, sans passer par des `if TYPE_CHECKING` malheureusement, je vois pas de solution, mais je suis pas sûr qu’il y’ai bcp de langages qui permettent d’exprimer ça simplement
21:01 <entwanne> ouais, c'est juste que je trouverais pratique de pouvoir exprimer "ce type a l'interface d'un namedtuple" comme on peut exprimer "ce type a l'interface d'une dataclass", sans avoir à explicitement être un namedtuple, je trouve qu'on perd là un aspect de Python justement (duck typing/ typage structurel)
21:05 <discord_afpy> <fred.et.rick> disons que c’est pas la même chose, l’un est un décorateur, l’autre passe par l’héritage, c’est plus facile d’exprimer "je prend un truc qui a n propriété et je te refile un callable qui prend ces n propriétés en paramètre et te renvoie une instance de type X" via un décorateur qui via de l’héritage
23:00 <entwanne> N'empêche qu'il y a souvent des cas d'usage qui ne sont pas exprimables avec le système de typage et qui sont comblés ensuite dans les versions suivantes (en exemple récent je pense à Unpack)
23:04 <discord_afpy> <fred.et.rick> je ne me suis pas interressé à Unpack, c’est implémenté en Python ou c’est une spec à par implémenté coté analyseur statique ?
23:06 <discord_afpy> <fred.et.rick> mais oui, ça fait plaisir de voir que le système de type s’étoffe au fur et à mesure des versions, ça laisse présager de bonnes choses pour l’avenir