Ressource Python

Salut,

Je serais bien en peine de te donner des ressources : la plupart des trucs que j’ai appris, je les ai lus dans la doc officielle (tant celle du langage qui explique comment ça a été pensé, que de la bibliothèque standard, que celle de l’API C de CPython, qui est une bonne entrée en matière pour découvrir les mécanismes internes), en expérimentant et en allant regarder le code source de CPython.

En ce qui concerne Pyglet, je me rappelle avoir joué avec il y a bien longtemps, à une époque où pygame était basée sur une version antédiluvienne de la SDL qui ne supportait pas OpenGL. J’en garde un excellent souvenir parce que cette bibliothèque est assez sexy et pythonique, et c’était un vrai plaisir à utiliser. Cela dit, pyglet est loin d’être aussi populaire que pygame, donc les ressources sont forcément un moins abondantes.

Le problème du Swinnen, c’est que c’est un cours de programmation (plutôt que de Python), et donc qu’il enseigne quelques trucs discutables du point de vue du langage lui-même. À vrai dire tout dépend du niveau : pour quelqu’un qui débute complètement, c’est une excellente ressource, mais je ne le conseillerais pas à quelqu’un qui sait déjà programmer et qui voudrait progresser spécifiquement en Python.

Je pense que dans le cas où tu veux simplment apprendre le langage et que tu as déjà les notions de base en programmation, le tutoriel officiel est le meilleur choix. Une introduction rapide et assez complète. Ensuite tu peux enchaîner sur le tutoriel d’entwanne ici-même.

Ce sera un excellent début.

Le tutoriel officiel (intégré à la documentation) paraît en effet être le meilleur choix si tu as déjà des connaissances en programmation.

Euh, non. C’est quoi le délire des versions de Python associées à celles de Windows (2.7 pour XP/Vista/W7 et 3.x pour W10) ?

Et la suite ne s’arrange pas.

L’auteur explique qu’il y a "3 types de variables principales" en Python, les entiers, les flottants et les chaînes de caractère. C’est complètement à côté de la plaque.

C’est pas mal pour un premier code ! J’aurais néanmoins quelques remarques.

• La méthode sub_money de ta classe Bank renvoie un booléen et vérifie que l’opération peut bien être réalisée, mais ces fonctionnalités ne sont jamais utilisées par le code du casino qui fait lui-même la vérification.
• Peut-être que la levée d’une exception serait plus adaptée qu’un retour de booléen ?
• Je ne suis pas fan des méthodes get_..., et en l’occurrence get_money n’apporte rien de plus qu’un simple accès à l’attribut money.
• Tout comme la classe Bank a au final peu d’intérêt, surtout que les garde-fous qu’elle propose ne sont pas utilisés.
• Une classe pourrait devenir utile si money prenait la forme d’une propriété pour assurer sa cohérence, mais est-ce bien utile ?
• Plutôt que d’avoir une boucle infinie dans casino.py, peut-être pourrais-tu boucler tant que la somme d’argent est strictement positive ?
• À quoi sert la variable start définie ligne 28 ?
• Tu indiques que le nombre choisi est compris entre 0 et 2 inclus, mais ce n’est pas ce que fait randrange(0, 2) (la borne supérieure est exclue).

En fait, si y’a un truc que je conseille en Python (notamment aux devs juniors de mon équipe au boulot), a fortiori aux gens qui connaissent déjà un langage OO classique comme C++, C# ou Java, c’est de s’interdire de penser avec des classes.

Il vaut mieux un code 100% utile avec des fonctions et les conteneurs standards (dictionnaires, listes, set, tuples…) que de créer des classes pour rien. La décision de créer une classe ne devrait venir que lorsque l’on a déjà un code qui fonctionne à peu près et/ou quand on a déjà une idée de comment la classe sera effectivement (et non serait éventuellement) utilisée.

La raison profonde, c’est que le paradigme OO s’exprime très différemment en Python par rapport aux langages cités plus haut, car ils ne sont pas pensés avec les mêmes priorités à l’origine : si une classe ne rend pas ton code plus court ni plus facile à comprendre, alors elle n’a aucun intérêt car elle ne le rendra ni plus rapide, ni plus facilement réutilisable.

Salut,

Ici, tu peux améliorer ton code en utilisant la négation booléenne. Dont ce cas, l’opposé de == est !=.

Et ici, tes break et ton else reviennent à la même chose. Je te laisse chercher comment simplifier ton code.

Pour la seconde partie, je ne pensais pas à ça. Ça ne sert à rien d’imbriquer le code du else dans un block parce que de toute façon si on rentre dans le if ligne 23, on ne pourra continuer grâce au break.

Et le OU booléen s’écrit or en Python.