Python
Un article de Haypo.
Version du 18 mars 2009 à 17:19 (modifier) Haypo (Discuter | Contributions) (→Introspection) ← Différence précédente |
Version actuelle (27 mars 2014 à 09:57) (modifier) (défaire) Haypo (Discuter | Contributions) (→Voir aussi) |
||
(117 révisions intermédiaires masquées) | |||
Ligne 26 : | Ligne 26 : | ||
[[Image:Boa petit prince.png|left|Un Python qui mange l'éléphant de PHP]] | [[Image:Boa petit prince.png|left|Un Python qui mange l'éléphant de PHP]] | ||
- | 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 [[# | + | 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 [[VM_Python#Optimiser_Python|la partie ci-dessous qui est dédiée à l'optimisation]]. |
<hr class="spacer" /> | <hr class="spacer" /> | ||
Ligne 32 : | Ligne 32 : | ||
__TOC__ | __TOC__ | ||
- | == | + | == Apprendre Python == |
- | + | [[Image:Apluggedinlife.jpg|thumb|500px|right|[http://apluggedinlife.com/fr/2011/02/16/developpeurs-php-demarrer-project-python-django/ Développeurs PHP, démarrez un nouveau projet sous Python/Django]]] | |
- | + | === Ressources gratuites === | |
- | + | ||
- | + | ||
- | En | + | En français : |
+ | * [http://perso.limsi.fr/pointal/python:courspython3 Initiation à Python 3] de Robert Cordeau | ||
+ | * [http://www.swaroopch.com/notes/Python_fr:Table_des_Matières A Byte of Python] (en français) | ||
+ | * [http://diveintopython.adrahon.org/ Plongez au coeur de Python] (''Dive Into Python'') | ||
+ | * [http://www.framasoft.net/article1971.html Apprendre à programmer avec Python] par Gérard Swinnen | ||
+ | ** [http://www.inforef.be/swi/python.htm Apprendre à programmer avec Python 3] par Gérard Swinnen | ||
+ | * [http://mat.oxyg3n.org/public/Python_10_min_French.pdf Apprendre Python en 10 minutes] ([http://mat.oxyg3n.org/index.php?post/2009/07/26/Python-en-10-minutes source du document]) | ||
+ | * [http://code.google.com/p/swfk-fr/ Domptage de serpents pour les enfants, apprendre à programmer en Python.] | ||
+ | * [http://www.afpy.org/wiki/DocumentsPourApprendrePython Documents pour apprendre Python] : Liste de l'AFPy | ||
+ | * [http://perso.limsi.fr/pointal/python:abrege Abrégé Dense Python 3.2] | ||
- | + | En anglais : | |
+ | * [http://inventwithpython.com/ Invent your own computer game with Python] | ||
+ | * [http://docs.python.org/tut/tut.html Tutoriel officiel] | ||
+ | * [http://homepage.mac.com/s_lott/books/python/html/ Building Skills in Python] | ||
- | === | + | === Par le jeu === |
- | + | * [http://www.pythonchallenge.com/ Python Challenge] | |
- | + | * [http://projecteuler.net/ Project Euler] : Jeux mathématiques | |
- | + | * pygame | |
- | + | === 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) | ||
- | == | + | == Pourquoi j'aime Python == |
- | + | === 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(), ...). | |
- | + | === 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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | === 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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | === 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). | |
- | + | === with === | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Mot clé with : "with open(fichier) as f: ...", "with verrou: ...", "with subprocess.Popen(...): ...", etc. | |
- | + | === 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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | === 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). | |
- | == | + | === 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)). | |
- | + | ||
- | + | ||
- | ** | + | |
- | + | ||
- | + | ||
- | + | === 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). | |
- | + | === 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. | |
- | === | + | === 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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | et | + | |
- | + | ||
- | + | === 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/ | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | == | + | === 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 !). | |
- | == | + | === 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). | |
- | == | + | === 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. | |
- | == | + | === Bonnnes pratiques : tests === |
- | Python est | + | 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. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | === 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. | |
- | === ... un autre langage (Java, Perl, C++) === | ||
- | + | == Python et ctypes == | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | Lire '''[[ctypes|Python et ctypes]]'''. | |
- | Il est possible de compiler un script Python pour produire un programme binaire. | ||
- | * Créer un binaire Windows (PE) | ||
- | ** [http://www.py2exe.org/ Py2exe] | ||
- | ** [http://starship.python.net/crew/atuining/cx_Freeze/ cx_Freeze] | ||
- | * Créer un binaire Unix (ELF) | ||
- | ** [http://wiki.python.org/moin/Freeze freeze.py] : Inclut dans Python apparement (?) | ||
- | == Valgrind == | ||
- | + | == Python et Unicode == | |
- | + | Lisez l'article dédié '''[[Python Unicode]]'''. | |
- | === Ressources gratuites === | ||
- | En français : | ||
- | * [http://diveintopython.adrahon.org/ Plongez au coeur de Python] (''Dive Into Python'') | ||
- | * [http://www.framasoft.net/article1971.html Apprendre à programmer avec Python] par Gérard Swinnen | ||
- | * [http://www.afpy.org/wiki/DocumentsPourApprendrePython Documents pour apprendre Python] : Liste de l'AFPy | ||
- | + | == 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 [http://docs.python.org/library/multiprocessing.html multiprocessing] pour éviter ce problème, module introduit dans Python 2.6. Il existe une version pour Python 2.4 et 2.5 : [http://pypi.python.org/pypi/multiprocessing 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é ... | ||
- | + | == 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'' | ||
== Voir aussi == | == Voir aussi == | ||
- | + | * '''[[Python ou rien]]''' — '''[[VM Python]]''' | |
- | + | ||
- | * '''[[ | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
* [http://www.afpy.org/ AFPY] : Association Francophone Python | * [http://www.afpy.org/ AFPY] : Association Francophone Python | ||
- | * [http://www.python.org/ python.org] : Le site officiel | ||
- | |||
- | ==== Documentation ==== | ||
- | |||
- | * [http://docs.python.org/lib/lib.html docs.python.org] : Documentation officielle (en anglais), avec ici un lien sur la référence de la bibliothèque officiel de Python | ||
- | * [http://wikipython.flibuste.net/moin.py/Traduction Projet de traduction de la documentation officielle complète en français] | ||
- | * [http://www.python.org/dev/peps/pep-0008/ Conseils sur le style de programmation en Python (PEP 8)] | ||
- | * [http://wikipython.flibuste.net/moin.py/JouerAvecUnicode Jouer avec Unicode] | ||
- | * [http://dosimple.ch/articles/Python-SWIG/ Tutoriel Python-SWIG] : Comment interfacer Python avec du C ou C++ | ||
- | * [http://www.bouil.org/w/Python_et_XML Python et XML (aide mémoire)] | ||
- | |||
- | ==== Projets intéressants utilisant en Python ==== | ||
- | |||
- | * [http://home.gna.org/oomadness/fr/slune/ Slune] : Jeu de voiture en 3D codé en Python (utilise Soya3D) | ||
- | * [http://sam.zoy.org/monsterz/ Monsterz] : Jeu très sympatoche codé en Python | ||
- | * [http://ipython.scipy.org/ IPython] : Shell écrit en Python ;-) | ||
- | * [http://www.gajim.org/ Gajim] : Client Jabber en GTK | ||
- | * [http://www.list.org/ Gnu Mailman] : Gestionnaire de liste de diffusion | ||
- | * [http://www.zope.org/ Zope] : Serveur d'application (HTTP) | ||
- | * [http://www.edgewall.com/trac/ Trac] : Outil « tout en un » pour la gestion de projet, c'est-à-dire : suivi de SubVersion, gestion de bug, gestion des tâches, wiki, etc. | ||
- | * [http://gramps-project.org/ GRAMPS] : Outil pour gérer sa généalogie | ||
- | * [http://www.tinyerp.com/ TinyERP] : Progiciel de gestion intégré (ERP) et gestion de la relation client (CRM) | ||
- | * [http://icculus.org/pyddr/ PyDDR] : Jeu de danse dans le style ''Dance Dance Revolution'' | ||
- | |||
- | Voir aussi : [http://www.pygtk.org/applications.html les applications qui utilisent PyGTK]. | ||
- | |||
- | De nombreux "gros" logiciels utilisent Python comme langage d'extension : OpenOffice, Inkscape, Scribus, Blender, ... | ||
- | |||
- | ==== Bibliothèques ==== | ||
- | |||
- | * [http://pymedia.org/ PyMedia] : Lire des fichiers Wav, Ogg, Mp3, etc. | ||
- | * [http://www.pygtk.org/ PyGTK] : Binding Python pour GTK+ | ||
- | * [http://www.riverbankcomputing.co.uk/pyqt/ PyQt] : Binding Python pour Qt | ||
- | * [http://twistedmatrix.com/trac TwistedMatrix] : Bibliothèque réseau haut-niveau très performante (et également toute une partie sur les traitements asynchrones) | ||
- | * [http://www.crummy.com/software/BeautifulSoup/ BeautifulSoup] : Permet de manipuler facilement des documents HTML « accidentés » (ne respectant pas la norme du W3C) | ||
- | * [http://www.jorendorff.com/articles/python/path/ module <code>path</code>] : Dans la même trempe que <code>os.join</code>, mais en bien plus puissant. | ||
- | * [http://sourceforge.net/projects/py-fate/ py-fate] : Framework contenant des proxys et algorithmes qui permettent d'écrire un programme résistant aux erreurs. | ||
- | * [http://pyro.sourceforge.net/ PYRO] : PYthon Remote Objects | ||
- | * [http://datamining.anu.edu.au/~ole/pypar/ Pypar] : Parallel Programming in the spirit of Python! (basé sur MPI) | ||
- | |||
- | ==== Divers ==== | ||
- | |||
- | * (en) [http://www.artima.com/weblogs/viewpost.jsp?thread=211062 Slides/Handout for "Code Like A Pythonista: Idiomatic Python" Available] | ||
- | * (en) [http://www.logilab.org/projects/pylint pylint] : Un programme note la qualité d'un code écrit en Python développé par Logilab (ceux qui bossent aussi sur PyPy) | ||
- | * (en) [http://www.python.org/dev/summary/ python-dev summaries]: Résumé de liste de discussion python-dev | ||
- | * (fr) [http://www.proformatique.org/spip.php?article86 Créer un navigateur web avec python] (8 janvier 2006) | ||
- | * (en) [http://www.cs.tut.fi/~ask/aspects/aspects.html A Light-weight Approach to Aspect Oriented Programming in Python] | ||
- | * (en) [http://cjkpython.i18n.org/ Python for CJK] (Chinese, Japanese, Korean) | ||
- | * (en) [http://unununium.org/ Unununium] : Système d'exploitation écrit en Python (enfin, une surcouche à un OS pour l'instant) | ||
- | * (en) [http://www.fluendo.com/elisa/ Elisa] : MediaCenter développé en Python par la société barcelonaise Fluendo (pro-formats libres tels que Ogg/Theora et Ogg/Vorbis) |
Version actuelle
« Python est à Perl ce que le système
métrique est au système anglo-saxon » — Palats
« Ce que j'aime dans Python, c'est que je peux passer l'essentiel
de mon temps de réflexion sur le code en simplifiant les idées
qui étaient inutilement tordues dans ma tête » — nil
« Chaque fois que je veux faire un truc, non seulement c'est faisable,
mais souvent c'est encore mieux que ce à quoi je m'attendais ! » — LePoulpe303
« Python est vraiment un language de flemmard » — Yoann512
« On se demande pourquoi les autres langages ont des syntaxes si compliquées » — glooze
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.
[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 :
[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