Cours Complet : La Récursivité En Python

Si tu souhaites devenir un expert de Python et apprendre à créer un code exceptionnel : developerssecr...
Si tu veux rejoindre une communauté de développeurs actifs et motivés : / discord

[@Sql37]

Ta présentation et tes explications sont bonnes mais il nous manque le pourquoi : un exemple ou un cas d'usage. Merci à toi pr le partage

[@raymar3658]

Hello merci pour cette vidéo, c'est un sujet "tricky" ! J'ai vu que tu utilises beaucoup de typing dans tes vidéos, est-ce-que tu pourrais faire une vidéo dédiée, qui explique les meilleures pratiques, par exemple comment structurer son code pour éviter des erreurs de références circulaires quand on utilise du typing. Sinon super contenu, merci beaucoup Dave, tu es en train de devenir le Corey Schafer francophone ! Update : Je viens de découvrir ta vidéo dédiée au typing 🙏 !

[@user-xx1kq6ot7i]

Faut faire des essais pour s'habituer mais ceci dit c'est super bien expliqué merci

[@codeavecdave]

Oui c'est pas facile au début. Merci beaucoup !

[@sebastientetaud7485]

clean gg :)

[@codeavecdave]

Merci beaucoup !

[@ApprendreSansNecessite]

Sur le plan de la pédagogie, je trouve ça un peu confusant. Comme je sense que tu aimes transmettre je vais prendre le temps de développer, mais je pense que ça peut aussi t'éclairer dans ton usage de la récursion. Tu représentes le problème comme une itération en décomposant les étapes du call stack (le fait de faire des print pour que l'apprenant voit où il en es est d'ailleurs très symptomatique de ça). C'est une façon classique d'enseigner la récursion mais je pense qu'elle va contre le paradigme et ne permet pas de gagner de la perspective. L'erreur que je vois tout le temps quand quelqu'un cherche à comprendre ou déboguer une fonction récursive, c'est de la dérouler dans sa tête. C'est une perte d'énergie, et je pense que cette pratique vient de cette technique d'enseignement et des habitudes de l'itération. Aussi, ça mène à des solutions récursives moins claires car trop impératives. Tu aurais pu rendre ton implémentation plus lisible par exemple en écrivant `if len(liste) == 0` ou `if not liste` (parce qu'une liste vide est falsy en python), et je vais expliquer pourquoi c'est plus lisible au delà de la cosmétique. Le principe de la récursivité, c'est d'implémenter le patron conceptuel "diviser pour régner". Ça se présente toujours de la même façon : "je ne sais pas résoudre X, mais je reconnais des sous-parties dans X que je sais résoudre en isolation et que je peux composer". Dans le cas de la somme d'une liste, en programmation fonctionnelle je ne peux pas itérer, parce que je ne peux pas maintenir un compteur mutable, par contre je peux additionner deux nombres et je peux extraire le premier élément et la queue d'une liste liée (le seul type de liste purement fonctionnel). C'est important de rappeler ces faits parce que autrement on trouve (à raison) arbitraire et inutilement compliqué d'utiliser la récursion pour faire une somme. La récursion résout toujours un problème, parfois purement récursif, d'autres fois simplement plus élégamment exprimé de façon récursive, mais il faut le nommer ce problème. Ce n'est pas un outil technique mais conceptuel. Donc, je peux décomposer le problème en deux cas : soit j'ai un cas trivial dont je connais la solution, c'est à dire la somme d'une liste vide (qui vaut 0), soit j'ai un cas problématique, c'est à dire la somme d'une liste non-vide, et là je dois me rapprocher du cas trivial, donc je vais en extraire un élément que je peux additionner. Reste à composer ces deux parties de solution en exploitant le fait qu'en programmation fonctionnelle on peut toujours substituer une expression par son résultat (parce qu'il n'y a pas d'effets secondaires) et c'est là que j'implémente l'appel récursif dans mon addition pour additionner le nombre que j'ai extrait, au résultat de l'appel récursif dont je sais qu'il sera 0 pour le cas de base, donc je retourne toujours un nombre. Du coup, pourquoi c'est pas bien de dérouler une fonction récursive dans sa tête ? Parce que la raison d'être de ce patron conceptuel c'est de ne pas avoir à le faire. On a juste besoin de penser au cas simple, à la façon de transformer le cas compliqué en cas simple, et à la façon dont les deux se composent. C'est purement déclaratif, pas impératif. Une fonction récursive non triviale est quasi impossible à dérouler dans sa tête (surtout quand il y a plus de 2 cas ou quand il y a du ping-pong entre plusieurs fonctions), et je ne compte plus les commentaires de développeurs frustrés qui pestent contre la récursion parce qu'ils ne savent pas lire du code récursif..