SAUVONS la planète (rien que ça) ! Arrêtons d'utiliser l'IDE Spyder. Dinopython 2.7 c'est terminé; Aujourd'hui c'est Python3+ ou rien. Alors que le langage évolue, nous attendons des Environnements de Développement Intégrés (IDE) stables qui suivent le mouvement.

Avec Python comme avec beaucoup d'autres langages, on peut coder avec un éditeur de texte (Gedit, Kate, Notepad++), voire de manière plus limitée, depuis la console. Néanmoins la coloration syntaxique peut laisser à désirer et bien qu'étant un langage interprété et non compilé, les allers-retours avec la console peuvent être fastidieux. C'est ici que les IDE ont leur carte à jouer; et tous ne se valent pas !

En effet, beaucoup sont ceux qui apprennent à coder avec des outils inappropriés pourtant proposés par défaut par leurs enseignants ou sur leur plateforme. Nous stigmatisons particulièrement ici l'IDE Spyder qui sous une apparence "conviviale" (R-Studio-like) génère bien plus de problèmes qu'il n'en résout à moyen terme...

Sommaire

Ce qu'on attend de la part d'un IDE

  • Coloration syntaxique;
  • Debugger intégré avec explorateur de variables;
  • Introspection du code (autocomplétion, etc.);
  • Indentation/désindentation automatiques;
  • Signalement des erreurs et avertissements en temps réel;
  • Recherche et surlignement instantané des occurrences de variables/fonctions;
  • STABILITÉ !

Spyder, ce qu'il devrait bien faire et qu'il ne fait pas !

Sur le papier, Spyder promet d'être un excellent IDE. Les problèmes commencent à survenir lorsqu'on utilise vraiment Python comme un langage de programmation et non comme un simple outil de script similaire à R. Pour faire court, lorsqu'on va plus loin dans le langage (au-delà d'OpenClassrooms), Spyder perd en stabilité, et adopte un comportement imprévisible.

Les nombreux effets de bord rencontrés sont liés au contexte global, conservé dans la console exécution après exécution. En effet, Spyder initialise un shell Python au démarrage, et utilise toujours le même par la suite pour exécuter le code.

LE MÊME PUTAIN DE SHELL !!#@!?!

Comme RStudio, Spyder permet de sélectionner des lignes et de les lancer de manière indépendante (puisque tout le reste a déjà été écrit, tout est dans le shell et est donc utilisable par nos lignes/fonctions solitaires).

Sauf que, de fait, ça créé un contexte global dans lequel le code tourne.

Imaginons:

  • On créé une variable globale avec une valeur, utilisée à plusieurs endroits dans le code.
  • Plus tard, on la supprime.
  • Là, on s'attend à avoir des erreurs dans le code, parce que la variable existe plus.
  • Mais en fait, non.
  • Elle existe encore.

Et les gens se plaignent d'avoir des erreurs bizarres ? Arrêtez d'utiliser des outils de merde, ça serait un minimum avant de gueuler sur un langage qui fait ce qu'il peut pour réparer VOS saloperies. Les problèmes liés à la maîtrise du langage sont suffisamment nombreux sans qu'on ait besoin d'ajouter ceux dus aux logiciels utilisés. On n'exécute pas un code Python à la volée comme on utilise un "code" R ! Pour cela il y a à la rigueur iPython.

Alors oui, pour éviter les effets de bord on peut/doit réinitialiser la console entre chaque exécution.
Cela veux dire que dans un contexte de test de code, le programmeur doit, selon ses préférences : * travailler avec un contexte global * réinitialiser la console entre chaque test

Le second cas est sûr, mais très contraignant. Le premier cas est dangereux. Lorsque vous testez votre code, vous ne devez jamais laisser deux tests se marcher dessus. Cela relève de la bonne pratique, et vous évitera de longues heures de debugging. Sérieusement.

Des preuves de tout cela ? Voir cet exemple typique d'un problème à la résolution chronophage généré par Spyder, où l'on observe très bien l'effet de Spyder sur la librairie standard, et où les seules solutions viables sont un tripatouillage difficilement justifiable du code ou l'utilisation d'un autre IDE.

Voici de plus une expérience personnelle assez flagrante : dans un contexte d'apprentissage de Python en université, une vingtaine de personnes de niveau équivalents se sont employées pendant un an sur des projets proches, mais avec des outils très variables. (OS, IDE, GUI et éditeurs différents)
Résultat : tous les étudiants ayant utilisé Spyder ont, de multiple fois, demandé de l'aide pour une erreur dû au contexte global. Erreur généralement résolue en changeant d'IDE, ou en redémarrant manuellement la console de Spyder. Finalement, une partie non négligeable de ces étudiants sont passés à d'autres éditeurs/IDE, et le reste conserve généralement de très mauvaises habitudes de programmation (test du code avec un contexte global).

Autres exemples d'erreurs franchement lassantes, dues à Spyder et qui devraient être évitées

Multiples importations de modules dans un contexte global : Logging, le nombre de logs s'incrément à chaque demande de création de Log.

Perte de console Python pour les nouvelles versions : Utilisateur perdu.
Et pourtant c'est tant mieux ! La console Python telle que sont utilisation est enseignée sous Spyder 2.7 est une ineptie...

Console imprévisible : stackoverflow.

Un nouvel IDE: Eric

Axé essentiellement sur le langage Python il est basé sur le très puissant composant d'édition de code Scintilla (tout comme Notepad++), et sur le framework Qt (Merci à QAnonym pour la précision !).

Plusieurs versions coexistent dans les dépôts; en théorie Eric 4 n'est censé gérer que Python2; toutefois l'exécution de code Python3 est rendue possible très facilement (sélection de l'interpréteur Python3 à la place de l'interpréteur Python2). Eric 5 quant à lui, supporte officiellement les deux versions de Python.

Eric permet de gérer facilement des projets incluant de multiples modules, de générer des diagrammes UML simples, d'afficher des statistiques sur le code, etc.

Bref, vous l'aurez compris, Eric est un IDE robuste et moderne qui ne plante pas comme Spyder, ce qui sera un gain de temps important pour ses utilisateurs...

Les différentes barres d'outils sont entièrement paramétrables voir détachables par glissés-déposés.

Je fournis mes feuilles de styles servant à la coloration syntaxique des codes Python, pour les deux versions d'Eric. Vous pourrez les importer via Settings/Preferences, Editor/Highlighters/Styles, Import all styles:

Page d'accueil du projet : Eric IDE.

PyCharm

PyCharm est un logiciel distribué sous deux licences, selon que vous utiliserez la version professionnelle propriétaire (orientée développement web avec Django, Flask, etc.), ou communautaire libre dédiée au développement Python "normal". Notez de plus que la version complète (Ultimate) est gratuite pour les étudiants & enseignants.

PyCharm semble être une bonne alternative à tester. Autocomplétion, vérification du code à la volée, debugger, contrôle de conformité à la PEP8, support de Python3.5, support des applications multithreadées; déplacement instantané au sein des fonctions présentes dans le code; renommage rapide des classes/méthodes/variables; raccourcis multiples; développement avec des frameworks comme Django facilité; support de gestionnaires de version tels que Git !.

Le programme est codé en Java. Il est donc plus long à lancer et l'interface est moins réactive qu'un logiciel classique.

Visualisation des Threads concurrents :

Vue générale du logiciel :

Gestion des erreurs/non-conformités avec les standards :

Vidéo officielle de présentation :

Page d'accueil du projet : PyCharm.

Autres IDE

Restent les "incontournables" Vim, Neovim, Emacs. Vous pouvez consulter le tableau comparatif des IDE dédiés à Python sur la documentation d'Ubuntu.

Python2 vs Python3 : Comment faire ?

La conversion Python2 vers Python3 est triviale.
Si vous êtes sur un code en Python2.7, activez le plus de comportements de Python3 possible en incluant des imports de __future__.


TOUTES LES DIFFERENCES entre les deux versions sont répertoriées sur ce site:python-future.org.

Celles qui sautent aux yeux sont au niveau de la gestion des divisions et de la fonction print():

  • __future__.print_function : remplace le mot clé print par la fonction print().
  • __future__.division : / devient la division classique, // la division entière.


Exemple : Vous ne savez plus comment récupérer les clés/valeurs de dictionnaires en Python2 ou Python3, ou comment faire un code compatible avec des dictionnaires ? Allez ici.
Note : En Python3, vous itérez sur l'objet tel quel; En Python2 vous parcourez une liste créée pour l'occasion en mémoire. Pour quelques milliers d'items ça passera mais pour des dictionnaires plus conséquents, si vous codez en Python2 vous allez voir votre RAM exploser. Pour rien :p


Exemple de point d'entrée, prêt à faire tourner du code Python3 avec l'interpréteur Python2.7:

# -*- coding: utf-8 -*-
"""
    Documenter le module ici.
"""

from __future__ import (unicode_literals, absolute_import,
                        print_function, division)

def main():
    """ Run the whole program """
    # votre code ici
    print('Hello !')

if __name__ == '__main__':
    main()


Pour finir, les tutos de Sam & Max constituent d'excellentes ressources, notamment sur la programmation orientée objet en Python. Sam & Max : Message de service aux débutants en Python.

Sources