[Python]Spyder, le super éditeur de code, et aide au debug

Dans ce thread, je vais tâcher de vous présenter Python, de mon point de vue d'ancien utilisateur de Game Maker.
Je ne m'attarderais donc pas sur l'histoire de Python, les questions over-techniques qui demandent une certaine connaissance que je ne possède pas nécessairement et j'éviterais la comparaison (comprendre le troll) avec des langages que je ne connais pas. De même, je zappe tout le coté open-source de Python, qui est très intéressant, mais n'a pas sa place ici.
Présentation plus approfondie de Python sur Wikipedia
Je précise également que cette présentation est MON avis personnel, ce n'est pas vérité absolue et je serais 100% subjectif.


Exemple de code Python, pour un projet personnel en cours utilisant wxPython, sous l'IDE Geany

Que peut-on faire avec Python ?

Spoiler:

La syntaxe de Python

Spoiler:

Python est haut-niveau

Spoiler:

Python est un langage interprété

Spoiler:

Python est un langage puissant

Spoiler:

Python est un langage riche

Spoiler:

============================================================
Bon, je finis ce très long post en vous présentant quelques bibliothèques.

à venir ce soir, j'en ai un peu marre là.
Note perso : faut aussi améliorer la mise en page

Très bonne idée de présenter ce langage mal connu et pourtant très bien!
Fut un temps,j 'avais commencé à apprendre, mais je suis jamais allé très loin :p

Pour ceux qui se demandent à quoi ça sert, ben ça sert à tout (des jeux par exemple, comme EVE online ont été faits en python, plein de softwares (inkscape pour ne citer que lui))!

Une question, quand on code en Python, au final on a un exécutable ou on garde le fichier de code (*.py je crois) et il faut installer un interpréteur.
Il me semble que c'est le 2) mais c'est pour être sûr et par flemme de chercher sur l'internet

Bah, de base, on garde le fichier .py, et il faut effectivement avoir un interpréteur Python.

Après, c'est surtout par commodité pour le programmeur. Une fois que tu as finis ton truc, tu peux très bien le mettre dans un exécutable, qui est en stand alone (=pas besoin pour l'utilisateur final d'installer Python) avec les bibliothèques adéquat.
Contrairement à Java, me semble-t-il, qui demande nécessairement sa (lourde) machine virtuelle.
Personnellement, je n'ai jamais développé un truc assez gros pour le distribuer sous Windows (principale raison des stand-alone en fait).

D'ailleurs, il y a aussi un truc que j'avais lu. Il y a apparemment plusieurs interpréteurs Python. Celui de base est en C.
Il y en a deux autres qui sont en Java et en C# (ou qui fonctionne avec le framework .NET, je ne sais plus). Est-ce que cela veut dire que l'on peut scripter en python, et que le code est ensuite compiler pour Java ou .NET ? Je crois que c'est cela. Mais sans en être sûr à 100%.

Ça me fait penser à un autre truc. Je disais plus haut que Python est interprété. Je crois qu'il est plutôt semi-compilé, ce qui explique ses performances. Maintenant, je ne connais pas encore le processus exact de cette simili-compilation.

Mh ok, ça peut être pas mal du coup, mais bon pour le moment j'ai pas trop le temps de me plonger dans un nouveau langage (même si j'avais appris des bases y'a quelques années).

Python a été élu langage de l'année par Tiobe et ça fait un moment que je voulais l'apprendre, parce qu'il a gagné énormément en popularité l'an passé. Voici un thread qui me donne encore plus envie. =D

En fait j'ai été obligé de comprendre sa syntaxe: https://gist.github.com/807839 pour le nouveau CBNA, parce qu'un des outils faisait quelque chose pas comme je le souhaitai et il était écrit en python et depuis j'ai envie d'apprendre.

Et hop, l'émulateur de chip8 largement inspiré de ce tutoriel du SDZ:

Spoiler:

Et le code source :
Sur google code
Je vous déconseille de le télécharger ou de l'exécuter, faut juste zieuter vite fait pour voir à quoi ressemble la programmation python, et un projet complet.


Bon, y a un tas de petits bugs concernant le moteur (que je ne résoudrai pas), et il me reste du fignolage à faire concernant le fichier principal (main.py), ce que je ferais.

Alors, c'est un programme sans grand intérêt dans l'absolu. On ne peut pas dire que ce soit follement amusant de programmer un émulateur. Surtout que le chip8 est une machine qui n'existe pas. Du coup, on a des spécifications théorique, mais rien de bien précis. Par conséquent, un peu tout est fait au pifomêtre.
Et puis, ça sert un peu à rien, vu les jeux pourrave qui ne fonctionnent pas dessus. Mais peu importe.

J'ai appris pas mal de petits trucs dessus. Et surtout, j'ai relativement bien organisé mon code, et ça fonctionne comme je l'avais imaginé sur papier.
Il y a d'un coté le moteur de l'émulateur proprement dit, qui fait un tas d'opérations les une à la suite des autres, et de l'autre coté, il y a l'écran, qui peut prendre n'importe quel bibliothèque graphique (ici, il y a Pygame et ncurse. J'avais aussi PySFML, mais je l'ai perdu comme un idiot en supprimant le mauvais fichier. Et j'ai aussi essayé de faire un truc en 3D avec soya3D, mais il ne veut pas fonctionner chez moi).
Chaque moteur est dans un thread, et le moteur graphique observe le moteur de l'émulateur pour afficher les bons trucs. Bon, j'ai un peu merdé sur l’implémentation du clavier, mais je pouvais difficilement avoir une classe qui fonctionne en parrallèle des deux autres.

Sinon, le python, j'ai l'impression qu'il a pris un sacré coup de boost depuis quelques versions. J'avais déjà remarqué cela avec le bench du topic idoine, et là, ça le confirme.
Avec ~250 opérations par secondes (bon, des opérations basique ceci dit), il utilise que ~10% de mon processeur sur le netbook. Ce qui est quand même très bon (du moins, au dessus de ce que j'espérais initialement). Par contre, pour l'affichage, ce n'est pas la joie. Autant, pour la version console, c'est réactif, autant, pour la version SDL, ça fait chauffer le processeur. Faut dire que tout est calculé par le processeur avec Pygame.

Bon, tout cela mérite de refaire un bon petit bench sous Python.

C'est clair que tes arguments donne très envie d'apprendre ce langage, malheureusement l'apprentissage demande du temps et j'en suis un peut à cour en ce moment. Ça m'a l'air plus simple que le C et c'est vrai qu'on en parle de plus en plus sur la toile. Je pense que quand j'aurai le temps je jetterai un oeil à quelques tutos.

En même temps niveau perfs, même en C la SDL est lente pour l'affichage.
Sinon j'avais appris python vite fait y a un petit moment pour l'utiliser sous Blender, et oui c'est un très bon langage de script, mais je n'y retrouve pas le plaisir de la programmation C/C++ (huhuhu oui je suis maso )

Et oui j'avais remarqué aussi que python ça carbure comparé a GM dès qu'on fait un peu de calcul, et ça c'était y a un moment.
Jsuis curieux de voir ton nouveau bench :p

Python est un langage qui a de nombreux avantages. Déjà, on a le choix de l'implémentation entre :

• CPython (implémentation "de base")
  
• Jython (implémentation utilisant la Machine Virtuelle Java)
  
• Psyco (compilateur à la volée, mais ne fonctionnant que sur les architectures 32 bits)
  
• IronPython (implémentation en C#)
  
• PyPy (implémentation en Python (WTF?))
  

Il y en a d'autres, mais celles-ci sont les principales.

Ensuite, ouais, je n'ai jamais vu in langage avec une syntaxe de base aussi simple pour un résultat aussi satisfaisant. Et en plus, ça n’exclue pas des principes parfois nouveaux et intéressants (les list comprehensions ou les les générateurs). Ses mots-clefs originaux sont tous très intéressants (le mot-clef "with" par exemple - rien à voir avec GM . Au final, en cherchant bien, il y a tellement de petits trucs partout que j'ai pour ma part trouvé le même plaisir que dans la prog C/C++.

En plus, Python étant un langage populaire, il possède un bon nombre de bibliothèques très intéressantes. Pour tout ce qui est calcul avec des tableaux par exemple, il existe l'excellente bibliothèque NumPy, et deux autres basées sur elle : SciPy qui fournit un nombre monstrueux de fonctions scientifiques et MatPlotLib qui est un "simulateur de Matab" en Python. Du coup, plus besoin d'utiliser un logiciel de calcul spécifique (Matlab, Maple, Scilab...), Python a une bibliothèque qui fait la même chose. On va aussi citer PyGames, la bibliothèque Python pour créer des jeux.
Toujours grâce à sa popularité, il a été prévu pour pouvoir s'interfacer avec d'autres langages.

Et puis bon, il a une bibliothèque standard de base assez gigantesque et qui couvre une bonne partie de ce dont on pourrait avoir besoin. Donc pour moi, c'est un des meilleurs langages à utiliser. Très agréable et aussi bien pour faire du procédural que pour faire de l'objet

Python, il y a deux paliers quand on l'apprend et on l'utilise.

Le premier, c'est quand on sait se servir des variables, classes, fonctions, utilisations des bibliothèques, etc.... Là, on se dit "ok, python, c'est bien, c'est concis et c'est expressif, mais ça n'apporte pas grand chose par rapport à un autre langage".
Le second, c'est quand on commence à découvrir la forêt derrière l'arbre. Les list et generator comprehension, les décorateurs, les structures de données, les primitives comme super() enumerate(), etc.... Et là, on se dit "comment j'ai pu vivre sans". La plupart, ce sont juste des fonctions raccourcis, mais mis bout à bout, ça donne un langage complet et orienté power-user, contrairement à ce que l'on pourrait penser. Et la performance suit.

Maintenant, je pourrais difficilement comparer au C++, vu que je sais uniquement le lire, mais pas l'écrire. J'imagine qu'ils sont complémentaire. De toute façon, je compte me mettre au C++ un de ces jours. Le seul truc qui me rebute, c'est l'écriture qui est trop abstraite pour moi dans un premier temps. Évidemment, ça passe, mais c'est difficile de passer outre pour commencer l'apprentissage.

C'était un message de la propagande pro-Python.

Je vais me mettre vite fais à python ta propagande marche

Pareille, j'ai commencé à lire les deux premiers chapitres du tuto sur le SDZ et honnêtement pour le moment ça me plais relativement bien comme langage.

Par contre, je ne sais pas ce que vaut le tutoriel du SdZ. Personnellement, je l'avais appris au départ avec ce tutoriel de Gerard Swinnen et un bouquin que j'ai acheté exprès. À l'époque, le tutoriel du SdZ sur python n'existait pas encore.

En tout cas, content que ma propagande marche.

Hop, je remonte mon thread. On va parler un peu d'IDE.

Pour ceux qui ne sauraient pas ce qu'est un IDE, c'est un environnement de développement. En gros, un logiciel qui est là pour, en principe, nous faciliter la vie quand on code.
Ça peut être un simple éditeur de texte un poil plus évolué que le bloc-note, mais ça peut être aussi une "usine à gaz" où en un click, tu peux compiler ton code, envoyer une commande au café du coin, traduire le code en tibétain et l'envoyer par sms à ton grand-père.


Un rapide résumé de mes besoins en Python :

Spoiler:

Alors, des IDE, y en a à la pelle sous Python. Mais c'est rare qu'il soit complet/intuitif/bien documenté/léger en ressource.

---

Avant ma migration en environnement Qt (KDE sous Linux quoi), j'utilisais Geany. C'était léger, simple, complet, cool. Y une screenshot dans le premier post.

Puis, je suis passé à Kate. Alors, grosso-modo, on retrouve les mêmes trucs que Geany, mais en Qt. C'est cool aussi. Mais il manque un tas de petit bidules qui simplifie la vie, genre la gestion de la documentation. Mais c'est quand même pas mal comme éditeur léger de code.

Spoiler:

---

Ensuite, j'ai eu une phase de test sur plusieurs machins. Je me souviens de KDevelop, avec ces icônes tout autour de la partie éditeur qui te donne l'impression d'être face à un ado boutonneux, du machin en Java ultra-connu qui te fait le café tout en pompant toute ta ram et ton cpu, puis un tas de déchets.

---

J'ai essayé de m'adapter à Eric, un IDE spécialisé Python. Alors, ce n'est pas Eric qui s'adapte à toi, mais toi qui t'adapte à Eric. Y a tout un tas de feature bien sympatoche, mais qu'est ce que c'est mal documenté ce logiciel. J'ai mis plusieurs heures pour réussir à activer l'autocomplétion (qui est pourrave), parce qu'il fallait soit même créer l'API Python. Ce n'est pas du tout compliqué à faire (en une ligne, c'est fait), mais bordel, pourquoi l'explication se trouve au fin fond d'une mailling list osbcure ?
Y a un pdf sur le site, mais à part lister les fonctions sans rien expliquer (du genre, "alors, sur la barre de menu, tu as Fichier/Affichage/Edition/etc... Comment, des explications ? Pourquoi faire ?"), il ne sert à rien.
Puis, je le trouve moche. C'est bête, mais ça me bloque.

Spoiler:

---

Là, je suis en train de tester un truc relativement obscur et peu connu (j'ai trouvé le lien sur stackoverflow, je crois). Spyder. Et à priori, ça m'a l'air vraiment pas mal du tout.
L'aide pour la documentation est pile-poil ce que je voulais, y a un debugger et un profiler vraiment intuitif, la coloration de code n'est pas trop mauvaise, et l'autocompletion est LOGIQUE. Allelluia.
Bon, j'ai quelques bugs graphique mineurs (du genre, quelques lettres qui disparaissent quand je sélectionne un bloc de texte, mais c'est plutôt Qt qui bug), ça manque d'un poil d'intégration avec KDE (bon, moins que l'ignoble Eric) et je n'ai pas encore testé cet IDE en profondeur pendant quelques jours, mais j'ai envi d'y croire.
À priori, il me manque juste un truc pour gérer Django, mais faudrait que j'aille voir les plugins disponible.

Spoiler:

Et la console interactive Python qui est vraiment jolie et incroyablement pratique pour savoir tout ce qui se niche en mémoire sans avoir à lancer des print(locals()) en tout genre.

Spoiler:

J'ajoute enfin que la documentation de Spyder est tout simplement génial et agréable à lire.

Tiens d'ailleurs en cours de math, on a fait du python, mais la prof elle faisait de grosses erreurs
De plus presque toute les personnes n'avaient jamais fait de programmation, et le programme contenait des boucles etc
Bref juste pour dire que le python est dans le programme de seconde.

jbg77 a écrit:

Bref juste pour dire que le python est dans le programme de seconde.

(ou pas)

J'avoue, on t'apprend à faire des algos (sauf que nous ont été tellement en retard qu'on en à pas fait :/) pas à coder en python. En TI-Basic peut-être et encore, comme nous on a été bénéficiaire du POP (Plan Ordinateur Portable) on peut éventuellement le faire avec des logiciels sur Linux du genre algobox et compagnie.

Après si on m'avait appris à coder en python, je m'en serais souvenu

Mass a écrit:

jbg77 a écrit:

Bref juste pour dire que le python est dans le programme de seconde.

(ou pas)

Ouvre un bouquin de math de seconde de cette année, et tu verras qu'on parle du python et qu'il y a des exos sur des algos en python

Ben, l'année dernière c'était sur Algobox, et sur le livre de seconde de cette année (parti prendre celui de sa cousine =P). Il y a encore Algobox, comme quoi. Après ça dépend peut-être des éditions, en effets.

Non, mais, ne vous cassez pas la tête sur ce point. Le python est recommandé suivant les académies, me semble-t-il. Puis, ça reste une recommandation, pas une obligation, tout comme le fait d'apprendre l'algo par l'informatique.

Python est certainement utilisé parce que pas mal utilisé dans le milieu scientifique, y a un tas de bibliothèque SERIOUS BUSINESS en math, on peut expédier l'apprentissage des bases du langages en deux heures et c'est interprété pour voir le résultat en direct. Puis, c'est sous une licence très permissive, ça permet de ne pas s'embarrasser de contrat ou de licence à acheter.
Mais vous n'apprendrez jamais à faire un jeu VIDÉO ou à fouiner en mémoire vive en cours de math, ça, c'est à peu près sur. On va pas devenir la soudaine patrie de milliers de Linus Torvald et John Romero.

Petit disclaimer :
J'ai traduis cet article depuis le blog de pythonconquerstheuniverse. Il concerne l'utilisation du debugger Python.
Il y aura une suite à cet article un peu plus tard, écrit par moi-même, pour expliquer comment un peu automatiser ce débuggage avec un IDE.
Pourquoi utiliser un debugger alors qu'on peut utiliser l'instruction print ? Parce que, si le code commence à devenir gros, des print dans tout les sens, ça commence à devenir ingérable. Et surtout, avec un IDE, ça devient rudement pratique et intuitif.
Et le debuggage permet d'aller fouiller les objets, les fonctions, d'essayer un tas de machins en temps réel, etc...
J'ignore si ce tutoriel peut s'appliquer en partie à gdb, le debugger pour C. Je me souviens qu'on peut lancer Python à l'intérieur de celui-ci, mais je n'en sais pas plus.
L'utilisation du debugger n'est pas réservé aux grands pros du python. Même si vous débutez en Python, vous pouvez vous en servir.

Et l'utilisation du print n'est pas non plus à proscrire totalement, c'est plus pratique dans le cas de petit scripts.

La traduction est "libérale". Je ne suis pas Google Translate ni professeur à la Sorbonne, j'y ai été à l'arrache.

---

Débugger un programme en Python
En tant que programmeur, une des premières choses dont vous auriez besoin pour un développement sérieux serait un debugger.

Python incorpore déjà un debugger, qui est disponible comme module nommé pdb (pour Python DeBugger). Malheureusement, la plupart des discussions concernant pdb sont difficilement accessible pour les débutants — elles sont très laconique et de simples resucées de la description de pdb dans la documentation de Python.

Donc, voici ma propre introduction à l'utilisation de pdb. Partons du principe que vous n'utilisez aucun IDE spécifique — vous codez avec un éditeur de texte des plus banals et vous lancez vos programmes Python depuis la ligne de commande.



Mise en route — pdb.set_trace()
Pour commencer, je vais vous montrer la manière la plus simple d'utiliser le debugger Python.

• Écrivons un petit programme, epdb1.py
  

  Code:

  
    # edpb1.py -- experimentation de pdb
    a = "aaa"
    b = "bbb"
    c = "ccc"
    final = a + b + c
    print(final)
   

• Insérons la déclaration suivante au début de ce programme.
  Cette déclaration importe le module de debuggage Python, pdb.
  

  Code:

  
    import pdb
   

• Maintenons, trouvons un endroit où nous aimerions inspecter le code, et insérons le code suivant.
  

  Code:

  
    pdb.set_trace()
   

  Désormais, le programme ressemble à cela :
  

  Code:

  
    # edpb1.py -- experimentation de pdb
    import pdb
    a = "aaa"
    pdb.set_trace()
    b = "bbb"
    c = "ccc"
    final = a + b + c
    print(final)
   

• Lancez le code depuis la ligne de commande:
  

  Code:

  
    PROMPT> python epdb1.py
   

Quand le programme rencontrera la ligne pdb.set_trace(), il va commencer l'inspection. Pour cela, il va :

1. s'arrêter,
   
2. afficher la "déclaration courante" (en fait, la ligne qui va être exécuter à la prochaine étape),
   
3. attendre une entrée.

Nous pouvons voir le prompt pdb, qui ressemble à :

Code:

  (Pdb)
 

Exécutons la prochaine déclaration... avec n" (next)
Dans le (Pdb) prompt, entrez la lettre n (pour "next") en minuscule, et appuyez sur Entrée. Cela va demander à pdb d’exécuter la déclaration courante. En répétant cette manipulation, vous finirez par quitter le programme, en retournant à la ligne de commande.

Félicitation ! Vous avez réalisé votre premier debuggage !



Répéter la dernière commande de debuggage... avec Entrée
Lancez de nouveau notre code, et entrez la lettre n dans le (Pdb) Prompt (comme vu plus haut) la première fois qu'il demande une instruction.
Une fois cette instruction donnée et exécuté, appuyons UNIQUEMENT sur Entrée, sans rajouter le n minuscule. Le code va continuer comme si un n avait été inséré.
Voilà donc le Truc #1 :

Citation :

Si vous pressez Entrée sans entrer quoi que ce soit d'autres, pdb re-exécutera la dernière commande entrée manuellement.

Dans cet exemple, la dernière commande était n (next), donc vous pouvez la ré-exécuter tout au long du debuggage en appuyant uniquement sur Entrée.



Tout quitter... avec q (quit)
Le debugger peut effectuer toute une foule de choses, dont certaines qui peuvent paraître un poil obscur. Mais la chose la plus importante à apprendre pour le moment est de quitter le debugger !

C'est facile. Quand vous voyez le (Pdb) prompt, pressez q (pour "quit") et la touche Entrée. Pdb va se terminer et vous retournerez à la ligne de commande. Essayez, et observez comment cela fonctionne.



Afficher la valeur des variables... avec p (print)
La chose la plus utile que vous puissiez faire avec pdb est d'afficher la valeur d'une variable. Voyons voir comment faire.

Lorsque vous êtes dans le (Pdb) prompt, entrez p (pour "print"), suivi du nom de la variable que vous souhaitez inspecter. Et, bien entendu, de valider la commande avec Entrée.

Notez aussi que vous pouvez afficher plusieurs variables en même temps, en séparant leurs noms par une virgule (comme une instruction Python régulière "print"). Par exemple, vous pouvez afficher la valeur des variables a, b et c de cette manière :

Code:

  (Pdb) p a, b, c
 

Quand est-ce que pdb exécute une ligne ?
Supposons que vous ayez progresser à travers le programme jusqu'à voir la ligne :

Code:

  final = a + b + c
 

et que vous demandiez la commande :

Code:

  p final
 

Vous auriez alors l'exception NameError. Pourquoi ?
Parce que, malgré que vous puissiez voir cette ligne, elle n'a pas encore été exécuté. Par conséquent, la variable final n'a pas encore été crée.

Maintenant, entrez n et exécutez cette ligne de code. Réessayez la commande "p final". Cette fois, pdb va afficher la valeur de final, qui est "aaabbbccc".



Couper le (Pdb) prompt... avec c (continue)
Vous aurez probablement notez que la commande q coupe pdb d'une manière particulièrement crue — en fait, en tuant le programme.

Si vous souhaitez simplement coupez le debuggage, mais laissez le programme s'exécuter normalement, entrez la commande c (pour "continue") dans le (Pdb) prompt. Cela forcera le programme a continué sans être mis en pause par le debugger.
Cette commande peut être lancé au démarrage, ou si l'instruction pdb.set_trace() se trouve à l'intérieur d'une boucle, elle continuera sans pause jusqu'à la prochaine rencontre avec pdb.set_trace(), où (Pdb) prompt réapparaîtra.



Voir où l'on se trouve... avec l (list)
Lors d'un debuggage, il peut y avoir plein de chose inscrit à l'écran, et il peut être dur de savoir où l'on se trouve actuellement dans le code.
La commande l (pour "list") est là pour cela.

l affiche sur l'écran la zone de votre code source où vous vous situez dans l'exécution courante. Par défaut, elle liste 11 lignes de code. La ligne de code où vous vous situez très exactement est au centre de cette zone, avec une petite flèche "->" pointant sur elle.

Pour résumer, voici une interaction typique avec pdb :

• La déclaration pdb.set_trace() est rencontrée, et vous commencez le debuggage avec le (Pdb) prompt.
  
• Vous pressez n et Entrée, pour passer à l'étape suivante du code
  
• Vous pressez Entrée pour une étape supplémentaire.
  
• Vous pressez Entrée pour une étape supplémentaire.
  
• Vous pressez Entrée pour une étape supplémentaire, etc...
  
• D'un coup, vous réalisez que vous êtes légèrement perdu. Vous n'êtes plus trop sûr où vous en êtes dans le code.
  
• Vous pressez l et appuyer sur Entrée. Cela liste la zone du programme où vous vous trouvez.
  
• Vous inspectez l'écran, retrouvez vos repères, et êtes prêt à "repartir".
  
• Vous pressez n et ensuite Entrée, pour passer à l'étape suivante.
  
• Vous pressez Entrée pour une étape supplémentaire.
  
• Vous pressez Entrée pour une étape supplémentaire.
  
• Vous pressez Entrée pour une étape supplémentaire, etc...
  

Entrer dans une séquence d'instructions... avec s (step into)
Vous pouvez avoir à debugger un gros programme — programme qui utilise des séquences d'instructions (fonctions, classes, etc...).
Et parfois, le problème que vous essayez de trouver se trouve profondément enfoui dans une de ces séquences. Considérons le programme suivant:

Code:

  # epdb2.py
  import pdb
 
  def combine(s1, s2):
      s3 = s1 + s2 + s1
      s3 = '"' + s3 + '"'
      return s3

  a = "aaa"
  pdb.set_trace()
  b = "bbb"
  c = "ccc"
  final = combine(a, b)
  print(final)
 

Durant votre navigation via pdb, en utilisant la commande n, dans ce programme, vous vous retrouvez devant une instruction qui invoque une autre séquence d'instructions — ici, l'instruction final = combine(a, b) — que pdb traite comme tout autre instruction. C'est à dire, l'instruction est executé et vous passez à l'instruction suivante — ici, print(final).

Supposez qu'il y ait un problème dans cette séquence d'instructions. Dans notre cas, supposons que vous suspectiez qu'il y ait un bug dans la fonction combine(a, b). Ce que vous voulez, c'est pénétrer à l'intérieur de cette fonction et la débugger de l'intérieur.

Bien entendu, vous pouvez le faire. Faites cela avec la commande s (pour "step into").

Lorsque vous exécutez une instruction qui ne provoque pas d'appel de fonctions, n et s font la même chose, passer à l'étape suivante du code. Mais lorsque vous exécutez une instruction qui invoque une fonction, s, contrairement à n, va pénétrer DANS cette fonction.
Dans notre exemple, si vous exécutez l'instruction

Code:

  final = combine(a, b)
 

en utilisant s, la prochaine instruction que pdb va afficher sera la première instruction de la séquence d'instruction

Code:

  def combine(s1, s2):
 

et vous continuerez la procédure de debuggage à l'intérieur de celle-ci.



Continuer... mais jusqu'à la fin de la séquence d'instructions actuelle... avec r (return)
Quand vous utilisez s pour pénétrez à l'intérieur d'une séquence d'instructions, vous vous retrouverez coincé à l'intérieur de cette séquence. Vous avez déjà examiné le code qui vous intéressais, mais maintenant, vous devez naviguer à travers un tas de ligne complètement inintéressante de la séquence d'instruction.

Dans cette situation, vous souhaiteriez être capable de sauter directement à la fin de la séquence. En fait, vous voulez faire quelque chose comme la commande c ("continue"), mais vous voulez aussi continuer le debuggage à la fin de la séquence d'instruction, et retournez en mode "pas-à-pas" dans le reste de votre code.

La commande pour cela est r (pour "return" ou, mieux, "continue until return"). Si vous êtes dans une séquence d'instructions et que vous tapez la commande r dans le (Pdb) prompt, pdb va exécutez sans interruption (sauf si vous l'avez demandez explicitement dans le code avec la fonction pdb.set_trace()) le code de la séquence en cours jusqu'à la fin. Arrivé à ce stade — stade de retour à la routine appelante — pdb va mettre en pause le programme et afficher de nouveau un (Pdb) prompt, où vous pourrez de nouveau naviguer à travers le code.



Faites n'importe quoi dans le (Pdb) prompt...
Quelques fois, vous pouvez vous retrouver dans la situation suivante : vous pensez avoir découvert le problème. Disons que l'instruction où vous affectez la valeur "aaa" à la variable var1 est fausse, et fait capoter votre jolie programme. Vous auriez dû affecter la valeur "bbb" à var1.

... enfin, disons que vous êtes quasiment sûr que le problème est situé là...

Ce que vous souhaiteriez réellement faire maintenant est d'affecter "bbb" à var1, et voir si le programme continue à s'exécuter sans exploser.

Une des choses les plus sympas avec le (Pdb) prompt est que vous puissiez faire n'importe quoi à l'intérieur de celui-ci — vous pouvez effectuer n'importe quelle commande. Bon, pour le moment, entrez cette commande dans le (Pdb) prompt :

Code:

  (Pdb) var1 = "bbb"
 

Maintenant, continuez à naviguer en mode "pas-à-pas" au sein de votre programme. Ou, si vous avec une âme d'aventurier suicidaire, utilisez c pour couper le debugger et voir si le programme explosera quand même avant la fin !



... Mais soyez quand même un peu prudent !
Maintenant que vous êtes le roi du pétrole dans le (Pdb) prompt, vous pourriez avoir envi d'essayer diverses choses, comme par exemple affecter "BBB" à la variable b.

Code:

  (Pdb) b = "BBB"
 

En faisant cela, pdb va afficher une étrange erreur, expliquant qu'il ne peut pas trouver un objet nommé '="BBB"'. Mais pourquoi ????

En fait, pdb va tenter d'exécuter la commande "b", qui configure et liste les breakpoints (une commande dont nous n'avons pas traité). Il va aussi interpréter le reste de la ligne comme un arguments pour la commande b, et ne pourra donc pas trouver l'objet dont il est question (en l’occurrence ici, '="BBB"'). Donc, il va lever un message d'erreur.

Comment donc affecter une nouvelle valeur à b ? Le truc est de faire débuter la commande par un point d'exclamation.

Code:

  (Pdb)!b = "BBB"
 

Ce point d'exclamation va permettre à pdb de comprendre que la commande est une instruction Python, et non une commande pdb.



The End
Voilà, c'est tout pour le moment. Il y a un grand nombre de points que je n'ai pas abordés ici, comme l'aide, les alias ou les breakpoints. Pour toutes informations les concernant, allez zieuter la référence pour les commandes pdb de la documentation officielle Python. En complément, je vous recommande l'article de Jeremy Jones, Interactive Debugging in Python dans le O’Reilly’s Python DevCenter.

En espérant que cette introduction à pdb vous sera utile [pleindeblablachiantàtraduire]. Bonne chance !

—Steve Ferg

Et voilà la suite de l'article. Cette fois-ci, j'en suis l'auteur.
C'est surtout un article de "promotion" pour cet excellent éditeur de code qu'est Spyder. Il est très peu connu, et pourtant, il a tout d'un grand.
Concernant le code présenté ici, c'est une partie de mon code qui est utilisé pour le moteur de carte d'un petit jeu que je fais. Vu que le projet sera sous licence libre, je m'en fous royalement si vous prenez les lignes de codes. De toute façon, on voit rien donc, ça m'étonnerais que ça arrive.
J'ai pris ce code, parce que c'est le dernier sur lequel j'ai bossé. C'est tout, ce n'est pas un super code et je suis loin d'en avoir terminé avec lui.
Et pour l'article, il est sous licence Licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé. En gros, vous en faites ce que vous voulez (modifier, vendre, diffuser, vous torcher avec au chiotte), du moment qu'il reste sous cette licence.
Et désolé pour les images zoomés, j'ai mal envoyé les images sur l’hébergeur. Du coup, ça a chié dans la colle. J'éditerais tout ce foutoir demain. Finalement, j'ai eu le courage de le faire dans la soirée.


Debugger un programme à l'aide de Spyder

Nous avons vu plus haut comment debugger un programme à l'aide de pdb. Avec l'aide de l'IDE Spyder ( qui est devenu mon éditeur de code python favori ), nous allons voir qu'il est possible de se passer de la première étape, c'est à dire l'import de pdb et mettre des marqueurs, via pdb.set_trace(), dans le code pour passer en mode pas-à-pas à certains points précis.
De nombreux autres éditeurs offrent ce type de fonction bien pratique au quotidien.



Marquer le code
Tout d'abord, nous nous déplaçons vers un endroit intéressant, où nous souhaiterions inspecter le code.
Ici, nous prendrons comme exemple une boucle qui a pour fonction d'instancier ( en python, tout est objet ) un caractère unicode, et de le "linker" dans une nouvelle instance Tile, qui est elle-même lié dans une liste-attribut de la classe Tileset. Ce caractère représente l'image provisoire avant que je crée en réel le moteur de sprite bitmap.
Pour résumer mon besoin, je suis curieux de connaître le caractère unicode correspondant à l'ID de la tuile.



Donc, je vais tagger cette ligne comme un point d'arrêt pour pdb. Pour cela, il me suffit :
- soit de double-cliquer dans l'espace gauche à coté de mon numéro de ligne.
- soit d'appuyer sur F12.
Et hop, le code est tagger à ce point précis comme devant être inspecter.



Maintenant, je lance le debugger. Pour cela :
- soit je passe par le menu exécution/debogger
- soit j'appuie sur la touche correspondante ( je l'ai personnalisé, j'ai donc la touche F6 ).

Et nous passons maintenant dans la console, qui se trouve en bas à droite chez moi ( chaque widget peut être déplacé à sa guise).



Inspection du code



Bon, je revois rapidement les commandes listés ci-dessus. Un "r" pour débuter, et hop, me voilà instantanément dans la boucle à inspecter. En passant, je vois que la partie éditeur ( à gauche, là où j'écris le code quoi ) place le curseur automatiquement à l'endroit où je suis dans le code. Bien pratique dans les longs codes sources.
Donc, je souhaite inspecter la variable locale "char" qui correspond à mon caractère unicode. En temps normal, j'aurais, si j'ai bien suivi le tutoriel plus haut, insérer "p char; r" pour afficher le caractère unicode et sauter au prochain saut de boucle.
Mais nous allons utiliser une petite feature de Spyder, l'affichage dynamique des variables locales.



Dans l'encadrée en haut, nous pouvons voir toutes les variables locales actuellement utilisés. Donc, la variable "char" vaut "@" et la variable "gid" ( correspondant à mon numéro de saut de boucle ici ) vaut 0. Mission accompli, je connais mon caractère unicode.
Je continue tranquillement de passer mon code avec la commande "r" jusqu'au saut de boucle 98.



Désormais, la variable "char" vaut "¢". Mais voilà, ce signe me rappelle de mauvais souvenirs, un monstre über-puissant dans mon roguelike favori. Je souhaiterais le modifier en "@" parce que ça représenté le héros dans ce jeu.
Deux possibilités :
- Soit je rentre la commande "char = '@'".
- Soit je double clique sur la case "char" et j'insère mon caractère @.
Et voilà, j'ai modifié dynamiquement une variable de mon code en mémoire. Et ce, en quelques secondes !
Évidemment, c'est un comportement stupide et allant à l'encontre de la logique de mon code. Mais ça, je m'en fous pas mal dans l'exemple de cet article.



Limitation de Spyder
L'affichage dynamique de spyder représente toutefois un petit défaut. Il n'affiche pas les objets qu'il ne sait pas analyser ( par exemple, nos classes personnelles ), et on ne peut donc pas modifier dynamiquement ces objets.
Par exemple, si j'ai un objet Orc avec des attributs HP et MP, je ne pourrais pas modifier ou lister graphiquement les attributs de cet objet. Il faut passer par la ligne de commande. C'est un peu dommage dans le cas d'un objet complexe, où l'on ne se souvient pas forcément de tout ses attributs et de toutes ses fonctions. Il faut donc fouiller dans le __dict__ de cet objet pour retrouver ce que l'on souhaite. Évidemment, ce n'est pas un énorme défaut, on a quand même le code sous les yeux en parallèle et il y a l'auto-complétion, et ce sera corrigé dans une prochaine version.



Pour conclure, trois petits bonus pour vous persuader d'utiliser ce magnifique IDE.


Bonus 1: l'inspecteur de code ( ou la documentation dynamique )



Dans l'encadrée en haut à gauche, Spyder affiche la documentation de la fonction ou de la classe en cours d'utilisation. Et cela, y compris pour votre propre code, à l'intérieur du module que vous éditez.
Par exemple, dans l'image, j'ai un peu plus haut dans le code ma classe Board. Il m'affiche les informations de signature de la classe, ainsi que la docstring que j'ai renseigné. En parallèle, il m'affiche la signature uniquement dans une infobulle en-dessous de mon curseur d'édition. Bien pratique quand une fonction prend pas mal d'arguments, ou pour éviter de switcher sans arrêt entre le navigateur internet et l'éditeur.
Un bémol toutefois, les bibliothèques mal documenté dans le code ne sont pas prises en compte. Par exemple, PySFML n'affiche rien, Pygame s'affiche car plus dans l'esprit python dans le code. Mais ça reste quand même relativement rare.


Bonus 2: Profiler le code ( ou connaître le temps d'execution de chaque partie de mon code )



C'est un outil de profiling, assez utile quand on a besoin d'optimiser son code. Il est possible de l'utiliser sans passer par Spyder, mais il devient bien plus intuitif avec celui-ci.
Bon, ici, le code n'est pas très bien choisi, parce qu'il n'y a aucune opération lourde, mais ça peut sauver un code qui bouchonne quelque part sans que l'on sache où vraiment. Et puis, on peut partir dans une course au benchmarking !


Bonus 3: Pylint ( ou avoir une note concernant son code )



Pareil que Profiler, c'est un outil stand-alone, mais bien intégré dans Spyder. Il donne une note à notre code.
Attention toutefois, c'est une note concernant principalement le respect des règles de syntaxe python ( par exemple, la célèbre PEP8 ) et la présence d'erreurs ou non dans le code. Cela ne notera pas votre algorithme, ni votre architecture de code, ce serait trop beau ( ou trop triste, c'est selon ).
L'utilité ? Harmoniser vos codes. En tentant d'atteindre le 10/10, vous aurez un code bien plus lisible, correctement documenté et qui respecte les conventions pour la relecture ultérieur de code. Et cela permet de partir sur de bonnes bases dans les travaux en équipe.
Et si vous tentez de l'utiliser sur un de vos modules python, ne soyez pas déprimé par l'affichage d'un 3/10 ( oui, ça m'est arrivé la première fois... ) ! Cela se corrige très facilement et vous progressez dans votre manière d'écrire un code.

C'est vraiment pas mal ces articles, faudrait les mettre en valeurs.

Bah, je ne cherche pas vraiment à ce qu'il soit en valeur. Je suis conscient que ça s'adresse à un auditoire relativement limité sur le CBNA. Faut aimer python quoi, et aller au delà des outils de base. Ça pose déjà pas mal de contrainte.
Mais si jamais, ça peut aider au moins une personne de passage, j'en serais déjà content.

Ceci dit, je ne crache pas dans la soupe, si vous voulez érigez une statue à mon honneur, pas de problème.


Sinon, j'utilise Tiled Map Editor. C'est un éditeur de carte. C'est pas trop compliqué et ça permet de réaliser rapidement des cartes. Bon, c'est limité, mais peu importe.
Ceci dit, y a un gros problème, le fichier de sortie. C'est du XML couplé à des images. Ce n'est pas plus mal qu'une autre solution, surtout pour un éditeur qui se veut universel. Mais c'est vraiment très ****** à exploiter.
Du coup, j'ai fait un script python pour convertir ce fichier XML dans un dictionnaire Python, et incorporer les images dans ce dictionnaire, par des chaînes de caractères (du coup, tout tient dans une seule structure). Et ce dictionnaire est enregistré dans un fichier.
Le lien google-code, le script est sous licence BSD
Y a déjà des scripts pour faire la conversion Tiled=>Python, mais c'est gros et ça nécessite des classes. Là, tout tient dans les structures de base de Python, et pas besoin d'importer quoi que ce soit d'autre (hormis cPickle, pour une question de logique).
Pour le moment, y a pas de support pour les layers Objets, mais ça ne saurait tarder, parce que je vais en avoir besoin.

L'utilisation, c'est
python convert-tiled-to-python <file-in.tmx> <myfile>

Bien évidemment, c'est un script qui continue à vivre, vu que j'en ai besoin. Du coup, ça sera souvent modifié, jusqu'à une version finale.

Voilà, zokaoù.

Bon je me suis mis au Python :
Alors déjà quelle fût le plaisir de télécharger une machine virtuelle de seulement 20 mo. Je dois dire que j'ai été vraiment très surpris par cette taille vraiment faible.
Après c'est parti, on peut directe se lancer, j'ouvre Notpad++, j'écris un code basique, j'enregistre avec l'extension .py. J'ai juste à double cliquer et le tout se lance.
La syntaxe à priori se révèle être pas mal, l’indentation pour les blocs d'instructions fait qu'au final notre code est propre.
On a pleins de bibliothèques intégrées c'est vraiment cool, pas besoins de se casser la tête.

Bon après pas de polymorphisme, le langage est moins riche que du C#
Mais je pense que c'est un bon langage pour débuter ou même tout simplement un bon langage

Bah a la base c'est un langage de script, et j'ai rarement vu des langages de script aussi évolués que C# & co. Leur but n'est pas la mais sur l’accessibilité et le coté pratique de la chose :p
J'en ai fait le semestre dernier pour la fac, on a appris a parcourir des dossier et traiter des fichiers x)
C'est tout con mais couplé aux regex ça permet quand même de faire des trucs vachement cool

Et ouai, python est un bon langage, puis en plus on peut l'utiliser dans Blender \o/

C'est vrai que c'est un langage de script tellement évolué que je le compare aux autres langages plus traditionnels.
Mais comparé à du Ruby, il est vraiment excellent :p

Bonjour. J'ai eu quelques soucis de pc ces derniers temps (j'ai dû m'en racheter un en urgence...).

Alors, concernant le polymorphisme, on peut en partie en faire. Au moins pourdériver de plusieurs classes, et pour la surcharge d'opérateurs.

Code:

class A:
    def testA():
        pass

class B:
    def TestB():
        pass

class C(A, B):
    pass

print(dir(C))
# ['__doc__', '__module__', 'testA', 'testB']

Code:

class A(object):
    def __init__(self, value):
        self.a = value
       
    def __add__(self, other):
        assert isinstance(other, A)
        return self.a + other.a
   
    def __repr__(self):
        return "<A.a = %i>" % self.a

a = A(10)
a2 = A(22)

string = "{} + {} = {}".format(a, a2, a + a2)
print(string)
#<A.a = 10> + <A.a = 22> = 32

Y a un troisième type de polymorphisme, mais j'ai oublié ce qu'il signifiait et effectivement, je crois me souvenir que ce n'est pas possible en Python.

Python pour débuter, clairement. C'est le premier langage que l'on apprend dans mon université, c'est qu'il y a une bonne raison.
Et par la suite, pour une utilisation avancée, ça reste toujours un bon langage. Je l'utilise quotidiennement à mon boulot, j'ai recodé des systèmes critiques "métiers" et les perfs sont là.
Après, pour les jeux (ce dont il est question ici), je suis partagé. Les performances sont excellentes, mais être excellent ne suffit pas pour les jeux. C'est un domaine qui a besoin de puissance brut (comme les OS, par exemple), et python peut malgré tout être largués dans des cas critiques.
Mais même pour ça, y a un tas de solutions :
- Utilisés avec des bibliothèques écrites en plus bas niveau. C'est ce que les pythonnistes font régulièrement en réalité. Python, C'EST du C en interne. Du moins, l'implémentation de base. Il y a des implémentations dans d'autres langages (java, C#, etc...) mais ça reste exotique, et quand on parle de python, on parle 99% du temps de son implémentation en C.
- Utilisés Cython. On écrit du code python, qui est traduit automatiquement en C. Il y a des trucs en plus (optionnel) utilisés en C. Par exemple, la déclaration statique des variables, pour l'optimisation de la compilation. Une fois le type de variable défini, il ne bouge plus.
Voici un exemple de code Cython, que j'utilisais pour travailler sur les valeurs hsv et rgb d'une image issus d'un widget Qt :

Code:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""
Created on Sat Jul 21 23:38:28 2012

@author: Sekigo

@licence : BSD -- http://www.freebsd.org/copyright/license.html

For compile this code :
    python setup.py build_ext --inplace

Composition of buffer image:
    32bits => Blue(8)-Green(8)-Red(8)-Alpha(8)
"""
import array

cpdef buffer_fading_to_color(buff, rgb, int intensity):
    if intensity == 0:
        return buff
   
    try:
#        TODO: Vérifier que les trois valeurs sont des int
        assert type(rgb) is tuple() and len(rgb) == 3
    except AssertionError:
        print("rgb need to be a tuple of 3 int")
   
    cdef int index
    cdef int r, g, b
    cdef int rf, gf, bf
    intensity = int(intensity / 255)
   
    rf, gf, bf = rgb
    for index in xrange(0, len(buff), 4):
        b, g, r = array.array('B', buff[index:index+3])
        r = intensity * (r - rf) + rf
        g = intensity * (g - gf) + gf
        b = intensity * (b - bf) + bf
        buff[index:index+3] = array.array('B', (b, g, r))
    return buff


cpdef buffer_set_alpha(buff, int alpha):
    cdef int index, a
   
    for index in xrange(0, len(buff), 4):
#        a = array.array('B', buff[index:index+4])[-1]
        buff[index+3] = array.array('B', (alpha,))
    return buff


cpdef buffer_set_invert_colors(buff):
    cdef int index
    cdef int r, g, b
   
    for index in xrange(0, len(buff), 4):
        b, g, r = array.array('B', buff[index:index+3])
        r, g, b = 255 - r, 255 - g, 255 - b
        buff[index:index+3] = array.array('B', (b, g, r))
    return buff


cpdef buffer_set_brightness_and_saturation(buff, int brightness, int saturation):
    cdef int index
    cdef int r, g, b
    cdef float h, s, v
   
    for index in xrange(0, len(buff), 4):
        # Invert canal blue and red
        b, g, r = array.array('B', buff[index:index+3])
        h, s, v = rgb_to_hsv(r, g, b)
       
        s = (s + saturation/359.0)
        if s > 1.0: s = 1.0
        if s < 0: s = 0
        v = (v + brightness/359.0)
        if v > 1.0: v = 1.0
        if v < 0: v = 0
       
        r, g, b = hsv_to_rgb(h, s, v)
        buff[index:index+3] = array.array('B', (b, g, r))
   
    return buff
   
cpdef buffer_shift_hue(buff, int shift):
    cdef int index
    cdef int r, g, b
    cdef float h, s, v
   
    for index in xrange(0, len(buff), 4):
        # les canaux bleu et rouge sont inversés
        b, g, r = array.array('B', buff[index:index+3])
        h, s, v = rgb_to_hsv(r, g, b)
        h = ((int(h*359) + shift) % 359)/359.0
        r, g, b = hsv_to_rgb(h, s, v)
        buff[index:index+3] = array.array('B', (b, g, r))
    return buff

cpdef buffer_image_set_partial_hue(buff, int hue, int old_hue, int precision):
    cdef int index
    cdef int r, g, b
    cdef float h, s, v, hh
   
    hh = float(hue)/359.0
   
    for index in xrange(0, len(buff), 4):
        # les canaux bleu et rouge sont inversés
        b, g, r = array.array('B', buff[index:index+3])
        h, s, v = rgb_to_hsv(r, g, b)
        if (old_hue - precision) <= (int(h*359)) <= (old_hue + precision):
            r, g, b = hsv_to_rgb(hh, s, v)
            buff[index:index+3] = array.array('B', (b, g, r))
    return buff

cpdef buffer_image_set_hue(buff, int hue):
    cdef int index
    cdef int r, g, b
    cdef float s, v, hh
   
    hh = float(hue)/359.0
   
    for index in xrange(0, len(buff), 4):
        # les canaux bleu et rouge sont inversés
        b, g, r = array.array('B', buff[index:index+3])
        s, v = rgb_to_hsv(r, g, b)[1:]
        r, g, b = hsv_to_rgb(hh, s, v)
        buff[index:index+3] = array.array('B', (b, g, r))
    return buff



cpdef rgb_to_hsv(int ir, int ig, int ib):
    cdef float r, g, b
    cdef float h, s, v
    cdef float rc, gc, bc
    cdef float maxc, minc
   
    r = ir/255.0
    g = ig/255.0
    b = ib/255.0
   
    maxc = max(r, g, b)
    minc = min(r, g, b)
    v = maxc
    if minc == maxc:
        return 0.0, 0.0, v
    s = (maxc-minc) / maxc
    rc = (maxc-r) / (maxc-minc)
    gc = (maxc-g) / (maxc-minc)
    bc = (maxc-b) / (maxc-minc)
    if r == maxc:
        h = bc-gc
    elif g == maxc:
        h = 2.0+rc-bc
    else:
        h = 4.0+gc-rc
    h = (h/6.0) % 1.0
    return h, s, v

cpdef hsv_to_rgb(float h, float s, float v):
    cdef int i
    cdef float f, p, q, t
    if s == 0.0:
        return int(v*255), int(v*255), int(v*255)
    i = int(h*6.0)
    f = (h*6.0) - i
    p = v*(1.0 - s)
    q = v*(1.0 - s*f)
    t = v*(1.0 - s*(1.0-f))
    i = i%6
   
    cdef int vv, tt, pp, qq
    vv = int(v*255)
    tt = int(t*255)
    pp = int(p*255)
    qq = int(q*255)
   
    if i == 0:
        return vv, tt, pp
    if i == 1:
        return qq, vv, pp
    if i == 2:
        return pp, vv, tt
    if i == 3:
        return pp, qq, vv
    if i == 4:
        return tt, pp, vv
    if i == 5:
        return vv, pp, qq

Mais je comprendrais aisément que pour les jeux, on préfère utiliser le C, ou tout autre langages bien plus performant.

En tout cas, avoir appris Python, c'est un choix que je ne regrette absolument pas. C'est un langage trousse-à-outil complet, qui est aussi bon en scripting qu'en programmation d'interface de logicel ou de développement web. Et qui "oblige" à avoir une bonne pratique de la programmation et d'écrire lisiblement.

Si je devais avoir une critique à faire à ce langage, c'est la communauté francophone quasi-inexistante sur le web. Y a bien le forum du sdz et le forum de développeur, ou encore linuxfr.org, mais ça n'a rien à voir avec la communauté anglophone, où par exemple Python trust la première place sur StackOverflow. Pourtant, y a pas mal de développeurs français qui connaissent le python. Mais la plupart se tournent vers la communauté anglophone (moi y compris).

Et aussi un petit truc pour les futurs pythonnistes sous Windows (sous Linux, c'est déjà moins utile avec le système de paquet). Installer et utiliser [url="https://pypi.python.org/pypi/pip"]PIP[/url]. Avec un simple

Code:

pip install pysfml

, ça installera/compilera/configura automatiquement les bibliothèques externes Python. Si j'ai un peu de temps cette semaine, je ferais un petit tuto.

A l'université nous on a commencé direct par le C
Python on l'a vite fait appris en L2 juste pour les regex x)