Python
Un article de Haypo.
Version du 30 janvier 2011 à 20:30 (modifier) Haypo (Discuter | Contributions) (→Python 3) ← Différence précédente |
Version actuelle (27 mars 2014 à 09:57) (modifier) (défaire) Haypo (Discuter | Contributions) (→Voir aussi) |
||
(62 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 33 : | Ligne 33 : | ||
== Apprendre Python == | == 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 === | === Ressources gratuites === | ||
En français : | En français : | ||
- | * [http:// | + | * [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://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://diveintopython.adrahon.org/ Plongez au coeur de Python] (''Dive Into Python'') | ||
Ligne 45 : | Ligne 47 : | ||
* [http://code.google.com/p/swfk-fr/ Domptage de serpents pour les enfants, apprendre à programmer en Python.] | * [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://www.afpy.org/wiki/DocumentsPourApprendrePython Documents pour apprendre Python] : Liste de l'AFPy | ||
- | * [http://perso.limsi.fr/pointal | + | * [http://perso.limsi.fr/pointal/python:abrege Abrégé Dense Python 3.2] |
En anglais : | En anglais : | ||
Ligne 64 : | Ligne 66 : | ||
* '''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) | * '''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. | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | C' | + | |
- | === | + | === 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. | |
- | + | === 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 === | |
- | + | ||
- | + | 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. | ||
- | S'il est important que le fichier soit fermé au plus tôt, il faut le fermer explicitement avec sa méthode '''close()''' : | ||
- | def affiche2(filename): | ||
- | f = open(filename) | ||
- | for line in f: | ||
- | print line.rstrip() | ||
- | f.close() | ||
- | print "EOF" | ||
- | ou plus élégamment avec '''with''' : | ||
- | def affiche3(filename): | ||
- | with open(filename) as : | ||
- | for line in f: | ||
- | print line.rstrip() | ||
- | print "EOF" | ||
== Python et ctypes == | == Python et ctypes == | ||
Ligne 310 : | Ligne 165 : | ||
Lire '''[[ctypes|Python et ctypes]]'''. | Lire '''[[ctypes|Python et ctypes]]'''. | ||
- | == Python C API == | ||
- | Lire '''[[Python C API]]'''. | ||
== Python et Unicode == | == Python et Unicode == | ||
Ligne 318 : | Ligne 171 : | ||
Lisez l'article dédié '''[[Python Unicode]]'''. | Lisez l'article dédié '''[[Python Unicode]]'''. | ||
- | == Import == | ||
- | Lisez l'article dédié '''[[Python import]]'''. | ||
- | |||
- | == Module subprocess == | ||
- | |||
- | Lisez l'article dédié '''[[Python subprocess]]'''. | ||
- | |||
- | == Introspection == | ||
- | |||
- | * dir(objet) : nom des attributs de l'objet | ||
- | * type(objet) : type de l'objet | ||
- | * getattr(objet, nom), setattr(objet, nom, valeur), delattr(objet, nom) : lire / modifier / supprimer un attribut selon son nom | ||
- | * isinstance(objet, type), issubclass(objet.__class__, classe), type(objet) == un_type, callable(objet) : teste le type d'un objet | ||
- | * Attributs d'une classe : | ||
- | ** cls.__name__ : nom de la classe | ||
- | ** cls.__bases__ : classes parent | ||
- | ** cls.__subclasses__ : classes filles (classes qui héritent de cls) | ||
- | * objet.__doc__ ou help(objet) dans l'interprète interactif : documentation de l'objet | ||
- | |||
- | Voir aussi le '''[http://docs.python.org/library/inspect.html module inspect]'''. | ||
- | |||
- | == Les différentes machines virtuelles == | ||
- | |||
- | Python est un langage. On peut compiler du Python pour donner du code machine i386, mais on peut aussi en faire du bytecode Java, ou plus couramment du bytecode pour la machine virtuelle CPython (l'interpréteur le plus connu). Voici donc une liste de machines virtuelles permettant d'exécuter du Python : | ||
- | * [http://www.jython.org/ Jython] : Exécution dans une ''Java Virtual Machine'' (JVM, voir [[Java]]). Voir aussi le projet [http://jpype.sourceforge.net/ Jpype] qui permet d'utiliser du Java dans Python. | ||
- | * [http://ironpython.com/ IronPython] : Dans une plateforme .NET avec intégration du ''Common Language Runtime'' (CLR) | ||
- | * [http://www.parrotcode.org/ Parrot] : Machine virtuelle en développement qui sera utilisée pour exécuter du Perl6 ou Python | ||
- | * [http://codespeak.net/pypy/dist/pypy/doc/news.html pypy] : Implémentation de Python codée en Python qui se veut aussi rapide que l'implémentation en C, voir même plus en utilisant une analyse dynamique du code ... | ||
- | * [http://www.stackless.com/ Stackless Python] | ||
- | |||
- | Script intéressant : [http://www.egenix.com/files/python/platform.py platform.py], donne diverses informations sur la plateforme exécutant le script Python. | ||
- | |||
- | == Convertir un programme Python en ... == | ||
- | |||
- | === ... un autre langage (Java, Perl, C++) === | ||
- | |||
- | * [[Cpp|C++]] : [http://code.google.com/p/shedskin/ Shedskin] (voir aussi le [http://shed-skin.blogspot.com/ blog de son auteur]) | ||
- | * [[Cpp|C++]] : [http://www.strout.net/python/ai/ Python2C], petit script très limité qui vise à convertir un script Python en C++ | ||
- | * [[C]] : [http://code.google.com/p/unpython/ unpython] | ||
- | * [[Perl]] : [http://perthon.sourceforge.net/ Perthon] | ||
- | * [[Java]] : [http://www.jython.org/ Jython] | ||
- | * Plateforme .NET : [http://ironpython.com/ IronPython] | ||
- | |||
- | === ... un binaire (Windows / Unix) === | ||
- | |||
- | 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 (?) | ||
- | |||
- | == Python 3 == | ||
- | |||
- | === Nouveautés === | ||
- | |||
- | * [http://linuxfr.org/2009/07/02/25680.html Python arrive en version 3.1] (2 juillet 2009) | ||
- | * [http://linuxfr.org/2008/12/05/24764.html Sortie de Python 3.0 version finale] (5 décembre 2008) | ||
- | |||
- | === Modules disponibles pour Python 3 === | ||
- | |||
- | * [http://regebro.wordpress.com/2010/04/29/zope-interface-3-6-0-released-with-python-3-support/ zope.interfaces] | ||
- | * [http://bitbucket.org/tarek/distribute/wiki/Home Distribute] (successeur de setuptools, compatible avec setuptools) | ||
- | * [http://code.google.com/p/gmpy/ gmpy] : interface GMP et MPIR | ||
- | * [http://pygments.org/ Pygments] : coloration syntaxique | ||
- | * [http://www.riverbankcomputing.co.uk/ PyQt] ([http://www.riverbankcomputing.com/news/pyqt-45 depuis la version 4.5]) | ||
- | * [http://www.pygame.org/ pygame] ([http://www.pygame.org/wiki/FrequentlyAskedQuestions#Does+Pygame+work+with+Python+3? à partir de la version 1.9]) : support néanmoins incomplet. Son successeur, [http://pygame.org/wiki/pgreloaded pgreloaded] supporte également Python3. | ||
- | * [http://pypi.python.org/pypi/bsddb3 bsddb3] | ||
- | * [http://pypi.python.org/pypi/py py (py.test, py.path, py.code)] | ||
- | * [http://mail.scipy.org/pipermail/numpy-discussion/2010-August/052522.html NumPy] (depuis août 2010) | ||
- | |||
- | Voir aussi la [http://pypi.python.org/pypi?:action=browse&c=533&show=all liste de modules compatibles Python3] sur l'index des paquets Python (PyPI). | ||
- | |||
- | Voir aussi [http://fedoraproject.org/wiki/Features/Python3F13#Porting_status Porting status], liste écrite pour Fedora. | ||
- | |||
- | === Portage en cours === | ||
- | |||
- | Portage en cours vers Python 3 (donc non utilisable en production) : | ||
- | * [http://wiki.python.org/moin/PortingDjangoTo3k Django] (devrait être fini à la [http://news.ycombinator.com/item?id=2130853 fin de l'été 2011]) | ||
- | * Zope : | ||
- | ** [http://regebro.wordpress.com/2010/01/08/2010-is-the-year-for-python-3/ 2010 is the year for Python 3!] | ||
- | ** (zope.interface a été porté, cf. plus haut) | ||
- | * pygtk : le portage de pyobject a débuté (voir ce dépôt git : [http://github.com/philn/pygobject/tree/py3k pygobject]), ticket associé : [https://bugzilla.gnome.org/show_bug.cgi?id=566641 Bug #566641]. Voir aussi [http://live.gnome.org/PyGObject PyGObject] (remplaçant de PyGTK ?) | ||
- | * [http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Roadmap+to+1.0 Pylons] : prévu pour Pylons 1.1, sans certitude | ||
- | * SciPy : [http://projects.scipy.org/scipy/roadmap#python-3 Roadmap (Python 3)], [http://www.scipy.org/Python3k Python3k] | ||
- | * [http://mail.python.org/pipermail/image-sig/2011-January/006636.html PIL] ([http://www.lfd.uci.edu/~gohlke/pythonlibs/ portage non officiel]) | ||
- | |||
- | === Status inconnu === | ||
- | |||
- | * Twisted: voir [http://twistedmatrix.com/trac/ticket/4244 ticket #4244] | ||
- | * Zope3 | ||
- | * PyCrypto | ||
- | * PyOpenSSL | ||
- | |||
- | === Distributions Linux === | ||
- | |||
- | ArchLinux utilise Python 3 comme interprète Python par défaut (programme "python") : Python 2 est accessible via le programme "python2". | ||
- | |||
- | Status le 16 avril 2010 : | ||
- | * Ubuntu : | ||
- | ** Karmic, Lucid intègrent Python 3.1 | ||
- | ** Jaunty intègre Python 3.0.1 | ||
- | ** Intrepid intègre une version RC de Python 3.0 | ||
- | * Debian : Python 3.1 est entré dans Debian Sid le 17 janviers 2010, voir les [http://packages.qa.debian.org/p/python3.1.html infos sur le paquet python3.1] | ||
- | * Fedora : [http://fedoraproject.org/wiki/Features/Python3F13 prévu pour Fedora 13] | ||
- | * Mandriva : [http://wiki.mandriva.com/fr/2010.0_Beta#Python Python 3 est disponible dans Mandriva 2010.0] (dépôt contrib) | ||
- | * Gentoo : [http://gentoo-portage.com/dev-lang/python Python 3.1.2] | ||
- | |||
- | === cmp === | ||
- | |||
- | La fonction cmp() et la méthode spéciale __cmp__ ont été [http://docs.python.org/py3k/whatsnew/3.0.html#ordering-comparisons retirée de Python 3.0] car c'était redondant avec la comparaison riche (méthodes __lt__(), __eq__(), ... utilisés avec a < b, a == b, ...), et que Python évite si possible la redondance (ça peut introduire des incohérences). On peut réimplementer la fonction cmp() si on en a vraiment besoin avec : | ||
- | def cmp(a, b): | ||
- | return (a > b) - (a < b) | ||
- | |||
- | Pour la migrer de Python 2 à Python 3, il est possible d'utiliser [http://docs.python.org/dev/library/functools.html#functools.cmp_to_key functools.cmp_to_key()] (introduite dans Python 3.2) qui convertit un callback de comparaison, pour la méthode sort par exemple, en function qui génère une clé (ex: sort(key=...)). | ||
- | |||
- | Python 3.2 introduit le décorateur [http://docs.python.org/dev/library/functools.html#functools.total_ordering @functools.total_ordering] qui permet de définir automatiquement toutes les méthodes de comparaison riche (__lt__(), __le__(), __gt__(), __ge__(), __eq__(), __ne__()) à partir de seulement deux méthodes : __eq__() et une autre méthode de comparaison au choix (ex: __lt__()). Si vous n'avez pas encore Python 3.2 (qui est prévu pour début février 2011 à l'heure où j'écris ces lignes), vous pouvez utiliser la recette [http://code.activestate.com/recipes/576529-total-ordering-class-decorator-for-filling-in-rich/ Total Ordering] de Christian Muirhead, Menno Smits et Michael Foord pour Python 2.6+ et Python 3.0+. | ||
- | |||
- | === Voir aussi === | ||
- | |||
- | * [http://pypi.python.org/pypi/six six] : Bibliothèque de compatibilité Python2 - Python3 | ||
- | * http://code.google.com/p/python-incompatibility/ | ||
- | * [http://pypi.python.org/pypi/py3to2 py3to2] | ||
- | * [https://fedorahosted.org/2to3c/ 2to3c] | ||
== GIL == | == GIL == | ||
Ligne 460 : | Ligne 189 : | ||
... // GIL est à nouveau verrouillé ... | ... // 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 == | |
- | + | * '''[[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://wiki.python.org/moin/UsefulModules Useful Modules, Packages and Libraries] | ||
- | * [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