Python

Un article de Haypo.

Version du 17 juillet 2012 à 21:06 (modifier) Haypo (Discuter | Contributions) (→Convertir un programme Python en ...) ← Différence précédente		Version actuelle (27 mars 2014 à 09:57) (modifier) (défaire) Haypo (Discuter | Contributions) (→Voir aussi)
(25 révisions intermédiaires masquées)

---

Version actuelle

Retour aux langages de programmation

---

[modifier] Présentation du langage

Python est un langage de programmation interprété possédant une grande bibliothèque de fonctions (ou modules). Ayant longuement programmé en C et C++, je trouve que programmer en Python (plutôt que C ou C++) est un grand gain de temps : aussi bien pour l'écriture du code que pour sa maintenance (débogage). La gestion des erreurs (ou exceptions) est bien meilleure : un programme ne plante pas, mais une exception est levée. Après, c'est au programmeur de bien gêrer les exceptions Python !

Au niveau des désavantages, six mois d'utilisation m'ont fait remarqué un défaut récurrent aux langages interprétés : il n'est pas possible de dire que le programme est stable. Il est toujours possible qu'une fonction inutilisée dans 99% des cas soit appelée, et là ... « c'est le drâme » (cf. 20h20). Le drâme est un appel d'une fonction ... qui n'est pas définie. Ce problème est détecté à la compilation en C.

Autre désavantage : Python est un langage interprété. Du coup, il est forcément beaucoup plus lent que des langages compilés comme le C (réputé pour sa vitesse). Il existe de nombreux projets visant à accélérer Python pour le rapprocher des performances d'un programme en C. Voyez la partie ci-dessous qui est dédiée à l'optimisation.

---

Sommaire 1 Présentation du langage 2 Apprendre Python 2.1 Ressources gratuites 2.2 Par le jeu 2.3 Ressources payantes 3 Pourquoi j'aime Python 3.1 Espace de nommage 3.2 Explicite 3.3 Exceptions 3.4 for x in y 3.5 with 3.6 Fonctions ayant peu d'arguments grâce à la POO 3.7 Lisibilité 3.8 Programmation fonctionnelle 3.9 Portable 3.10 Intégration aisée des bibliothèques existantes 3.11 Bonnes pratiques : docstring 3.12 Bibliothèque standard 3.13 Nombreux types de base 3.14 Fonctionnalités bien séparés et uniques 3.15 Compatibilité ascendante 3.16 Bonnnes pratiques : tests 3.17 Syntaxe générique et homogène 4 Python et ctypes 5 Python et Unicode 6 GIL 7 Défauts de Python 8 Voir aussi

[modifier] Apprendre Python

[modifier] Ressources gratuites

En français :

• Initiation à Python 3 de Robert Cordeau
• A Byte of Python (en français)
• Plongez au coeur de Python (Dive Into Python)
• Apprendre à programmer avec Python par Gérard Swinnen
  • Apprendre à programmer avec Python 3 par Gérard Swinnen
• Apprendre Python en 10 minutes (source du document)
• Domptage de serpents pour les enfants, apprendre à programmer en Python.
• Documents pour apprendre Python : Liste de l'AFPy
• Abrégé Dense Python 3.2

En anglais :

• Invent your own computer game with Python
• Tutoriel officiel
• Building Skills in Python

[modifier] Par le jeu

• Python Challenge
• Project Euler : Jeux mathématiques
• pygame

[modifier] Ressources payantes

En français :

• Programmation Python de Tarek Ziadé : référence Python 2.4 en français accessible aux débutants en Python
• Petit guide à l'usage du développeur agile de Tarek Ziadé : bonnes pratiques pour programmer en Python (bien que les pratiques puissent s'appliquer à d'autres langages)

[modifier] Pourquoi j'aime Python

[modifier] Espace de nommage

On contrôle très finement l'espace de nommage d'un fichier. On connait exactement quels sont les symboles importés lorsqu'on importe un module : "import sys" ajoute le symbole sys, "from sys import version" ajoute le symbole version. Par exemple, #include <stdio.h> en C importe des centaines de macro, constantes et fonctions. Il n'y pas de variable super globale et peu de fonctions globales (contrairement à PHP qui en a des centaines). Chaque classe et chaque fonction est également un espace de nommage. Les fonctions de la bibliothèques standards sont rangés dans des modules. Du coup, on ne retrouve pas avec des noms préfixés (exemple avec les fonctions iconv en PHP : iconv_get_encoding(), iconv_strlen(), ...).

[modifier] Explicite

Il n'y pas de variable magique ou argument magique sorti de nul part. Tout est explicite. Le code Python est généralement plus verbeux que Perl, mais il est assez facile de comprendre un code Python inconnu.

[modifier] Exceptions

La gestion des erreurs par l'utilisation d'exception est utilisée quasiment partout. Pour ignorer une erreur, il faut le faire explicitement. La gestion d'erreur est plus simple qu'en C par exemple : si une fonction ne souhaite pas gérer l'erreur elle-même, elle n'a pas besoin de remonter l'erreur explicitement à la fonction appelant. En C, si on omet de tester explicitement la valeur de retour d'une fonction, ou bien de remontrer l'erreur à la fonction appelant, on peut perdre des données (fichier corrompu silencieusement, plantage si on omet de vérifier que malloc() n'a pas échoué, etc.). En Python, une erreur d'allocation mémoire lêve une exception MemoryError.

try/finally est pratique pour exécuter du code qu'une exception soit levée ou non.

[modifier] for x in y

Parcourir n'importe quel type d'ensemble se fait facilement avec une syntaxe claire, "for x in y: ...". En C, il faut gérer manuellement la boucle (initialisation, condition de fin, passer à l'élément suivant).

[modifier] with

Mot clé with : "with open(fichier) as f: ...", "with verrou: ...", "with subprocess.Popen(...): ...", etc.

[modifier] Fonctions ayant peu d'arguments grâce à la POO

Les types de base (nombres, chaînes de caractère, liste, dictionnaire, ...) sont des objets, les classes et les fonctions sont des objets, etc. La bibliothèque standard utilise massivement la programmation orientée objet. Du coup, les fonctions (méthodes) ont peu d'argument et on se trompe moins facilement. Par exemple, fgets(s, size, stream) a 3 arguments en C, alors que fichier.readline() n'en a aucun. De même, l'opérateur "in" évite de se tromper dans l'ordre quand on cherche un élément dans un ensemble : "x in y" est explicite, alors que pour in_array($x, $y) en PHP ou strstr(x, y) en C je dois relire la documentation de temps à autre pour vérifier l'ordre des arguments.

[modifier] Lisibilité

Grâce à l'indentation obligatoire et la PEP 8, il est facile de relire le code d'un autre projet et le reprendre dans son projet (en respectant sa licence bien sûr).

[modifier] Programmation fonctionnelle

Les générateurs (yield dans une fonction) et les list comprehension ont un goût de programmation fonctionnelle et permettent facilement d'écrire des algorithmes complexes. Diviser pour rêgner. La plupart des types de base acceptent un générateur en argument, exemple : list(x**2 for x in range(10)).

[modifier] Portable

Python est réellement portable. Python s'abstrait du matériel : les nombres entiers ont comme limite la mémoire vive et le texte est stocké en Unicode. Python cache les détails de chaque architecture pour offrir une API homogène sur tous les systèmes. Python gère la mémoire tout seul (avec un ramasse miettes).

[modifier] Intégration aisée des bibliothèques existantes

Il est facile d'utiliser des bibliothèques existantes écrites dans d'autres langages (surtout en C) en Python. Avec le module ctypes, c'est on ne peut plus trivial.

[modifier] Bonnes pratiques : docstring

Les fichiers, classes et fonctions peuvent être documentées brièvement à l'aide de docstrings. Du coup, la commande help() de l'interprète Python fonctionne sur la majorité des fonctions et classes.

[modifier] Bibliothèque standard

Python est livré de base avec :

• réseau : chiffrement (SSL/TLS), clients HTTP, XML-RPC, POP3, IMAP ... et serveurs HTTP, XML-RPC, ...
• archive : bzip2, gzip, tar, ZIP
• gérer des processus
• gérer un système de fichier (ex: copier/supprimer un dossier)

http://docs.python.org/library/

[modifier] Nombreux types de base

• int
• bytes / str
• tuple
• list
• dict
• set

Chaque type a de nombreuses fonctionnalités. Ces types de base sont performants : implémentés en C, ils utilisent par exemple des algorithmes de hash pour la vitesse.

Le type set est très pratique pour supprimer les doublons d'un ensemble ou tester qu'on élément fait déjà parti d'un ensemble. Il me manque en C par exemple (mais pas autant que list !).

[modifier] Fonctionnalités bien séparés et uniques

Les types de base ne font pas le café et chaque module Python répond à un besoin bien défini.

Ruby a par exemple fait le choix d'ajouter une méthode .times aux nombres pour exécuter une boucle. En Python, les boucles ne font avec les mots clés for et while uniquement.

Dans la mesure du possible, il y a une seule manière de faire une chose. Contre exemples : modules getopt, optparse, argparse (duplication liée à la compatibilité ascendante).

[modifier] Compatibilité ascendante

Python assure la compatibilité ascendante dans toute la vie d'une version majeure de Python. Il y beaucoup de chance qu'un programme écrit pour Python 2.0 fonctionne sur Python 2.7.

Par contre, cette garantie n'est pas forcément respectée par les modules tiers. D'ailleurs, les modules tiers écrit en C doivent être recompilés pour chaque version mineure (2.x) de Python, et l'API C de Python a une moins bonne compatibilité ascendante que l'API Python.

[modifier] Bonnnes pratiques : tests

Développer un projet en Python est moins long qu'en C par exemple car Python offre beaucoup de facilités : gestion automatique de la mémoire, exceptions, bibliothèques existantes, etc. Du coup, le temps "gagné" peut être utilisé pour écrire des tests. Les tests servent à compenser certaines lacunes de Python comme la vérification du type des arguments d'une fonction ou les erreurs qu'on n'a qu'à l'exécution. Mais ils sont obligatoires pour le refactoring d'un projet, et je considère que le refactoring est nécessaire dans la vie d'un projet. Sans refactoring, le code d'un projet est voué à grossir et se complexifier. Les développeurs initiaux vont finir par quitter le projet tôt ou tard, et plus personne ne sera capable de faire évoluer le projet.

[modifier] Syntaxe générique et homogène

"for x in y: ...", "x in y", "if x: ..." : de nombreuses instructions sont identiques qu'importe le type des données. On peut donc écrire du code générique qui accepte n'importe quel type de données, et la syntaxe est facile à relire.

[modifier] Python et ctypes

Lire Python et ctypes.

[modifier] Python et Unicode

Lisez l'article dédié Python Unicode.

[modifier] GIL

CPython utilise un verrou global pour tout l'interprète Python (Global Interpreter Lock). Même si on utilise des threads, un seul interprète fonctionne à la fois. On peut utiliser le module multiprocessing pour éviter ce problème, module introduit dans Python 2.6. Il existe une version pour Python 2.4 et 2.5 : Backport of the multiprocessing package.

En réalité, le GIL est relaché pour de nombreuses opérations bloquantes et par de nombreux modules écrits en C. Quelques exemples :

• Modules bsddb, curses, ossaudiodev, fcntl, multiprocessing, sqlite3, tkinter, hashlib (MD5, SHA1, ...), posix, select, socket, zlib, bzip2
• Opérations sur un fichier (ouverture, lecture, écriture, fermeture, ...) : concerne un grand nombre de modules
• Fonctions thread.lock().acquire(), time.sleep(), syslog.syslog(), signal.pause()

En C, le GIL est relaché par les instructions suivantes :

... // GIL est verrouillé ...
Py_BEGIN_ALLOW_THREADS
... // GIL relaché : plusieurs threads peuvent s'exécuter en même temps ...
Py_END_ALLOW_THREADS
... // GIL est à nouveau verrouillé ...

[modifier] Défauts de Python

• Documenter un module demande de faire le travail deux fois : docstring et document reST (fichier(s) .rst)
  • Les docstrings sont plutôt la documentation bas niveau (documentation de l'API), alors que la documentation au format reST est la documentation utilisateur (moins complète, mais plus éducative, organisée, avec des exemples).
  • Le format docstring ne permet aucun mise en format, alors que reST offre beaucoup d'outils de mise en forme et permet de créer des liens entre les fonctions et modules
• La bibliothèque standard n'est mis à jour que tous les 18 mois (durée entre deux mises à jour majeures de Python)
  • Pour un correctif, il faut attendre 18 mois
  • Pour une nouvelle fonctionnalité, il faut attendre 18 mois
  • Avoir une grosse bibliothèque standard évite d'avoir des dépendances externes et simplifie dans l'installation d'applications Python
  • Avoir la bibliothèque standard dans le code source de Python permet aux développeurs de Python de mettre à jour cette bibliothèque en même temps que le langage et l'interprète (ensemble plus homogène
• La bibliothèque standard n'est pas très homogène. C'est surtout le cas dans Python 2 : nom de modules et des fonctions ne respectant pas les dernières conventions comme la PEP 8.
  • La bibliothèque standard a été nettoyée en profondeur (surtout du côté des noms de modules et de fonction) dans Python 3

[modifier] Voir aussi

• Python ou rien — VM Python
• AFPY : Association Francophone Python