Un an et sept mois après Python 3.1, voici une nouvelle version majeure de Python 3 : la version 3.2. Elle apporte notamment deux nouveaux modules (argparse et concurrent.futures), des améliorations sur les extensions écrites en C (API stable et marquage dans le nom de fichier des bibliothèques) et les modules compilés (fichiers .pyc) sont désormais rangés dans un dossier « __pycache__ ». Pour rappel, Python 3 corrige les erreurs de jeunesse de Python et harmonise la bibliothèque standard (relire la dépêche annonçant Python 3.0).
Pour faciliter le travail des développeurs des autres implémentations de Python (IronPython, Jython, Unladen Swallow, PyPy), la syntaxe, la sémantique et les fonctions builtins n'ont pas changé dans version 3.2, comme décidé par le moratoire (PEP 3003: Python Language Moratorium). Le moratoire prend fin avec la publication de Python 3.2.
La seconde partie de la dépêche présente en détail les nouveautés de Python 3.2, l'état du portage des modules vers Python 3, et évoque ce qui est prévu pour la suite.
Sommaire
-
- Nouveautés de Python 3.2 : nouveaux modules
- Nouveautés de Python 3.2 :
__pycache__et extensions - Nouveautés de Python 3.2 : certificats (HTTPS)
- Nouveautés de Python 3.2 : optimisations et verrou global (GIL)
- Nouveautés de Python 3.2, en bref :
- Nouveautés de Python 3.2 : ce n'est pas fini !
- État du portage des modules vers Python 3
- Porter votre projet vers Python 3
- Et pour la suite…
Nouveautés de Python 3.2 : nouveaux modules
« PEP 389 : argparse. » Le nouveau module argparse vise à remplacer le module optparse (qui, lui-même, remplace getopt) : il gère les arguments positionnels, les sous-commandes, les arguments obligatoires, etc..
« PEP 3148 : concurrent.futures. » Le nouveau module concurrent.futures est une interface de haut niveau pour gérer indifféremment des processus légers (threads) ou des processus. Une tâche est représentée par un objet Future qui permet de lire l'état (en cours ou terminé), annuler la tâche, ajouter des fonctions de rappel, etc.. On peut lire le résultat ou l'exception avec un délai maximum exprimé en secondes.
Nouveautés de Python 3.2 : __pycache__ et extensions
« PEP 3147 : PYC Repository Directories (__pycache__) ». Le nommage du bytecode mis en cache (fichiers avec extension « .pyc ») ne fonctionne pas dans un environnement avec plusieurs interprètes Python. Chaque interprète écrase le cache des autres interprètes. Cette guéguerre des « .pyc » est plus prononcée depuis que les distributions Linux embarquent plusieurs versions de Python, et surtout avec l'arrivée de nouveaux interprètes comme Unladen Swallow. Le nom des fichiers PYC contient désormais le nom de l'interprète (ex : « os.cpython-32.pyc » pour le module « os ») et les fichiers sont rangés dans un dossier à part (__pycache__) pour éviter de polluer les dossiers sources.
« PEP 384 : API stable » : pour éviter d'avoir à recompiler les extensions Python pour chaque version de Python installée sur le système, un sous-ensemble de l'API Python a été défini comme étant l'API stable. En contrepartie, la structure interne des objets devient par exemple opaque, il faut utiliser des fonctions de plus haut niveau pour manipuler les objets. La finalité est de pouvoir distribuer un seul binaire par plate-forme pour toutes les versions de Python (à partir de la version 3.2).
« PEP 3149 : ABI Version Tagged .so Files. » De même que pour les fichiers PYC, le nom de fichier des extensions peut également être marqué avec le nom de l'interprète et des drapeaux de compilation (ex : « d » pour debogage, « m » pour pymalloc, « u » pour Unicode sur 32 bits). Il est alors possible de ranger les extensions au même endroit pour plusieurs implémentations de Python et plusieurs versions du même interprète (ex : Python 3.2 et Python 3.2 compilé en mode débogage).
Nouveautés de Python 3.2 : certificats (HTTPS)
La nouvelle classe « ssl.SSLContext » est un conteneur pour les données SSL persistantes comme les paramètres du protocole, certificats, clés privées et diverses options. « poplib.POP3 », « ftplib.FTP_TLS », « http.client.HTTPSConnection » et « urllib.request.HTTPSHandler » acceptent cette nouvelle classe. « urllib.request.urlopen() » ne supporte pas encore SSLContext, mais a deux nouveaux arguments pour vérifier le certificat du serveur.
Il est donc désormais possible de vérifier le certificat du serveur auquel on se connecte en SSL ou TLS, mais ce n'est pas fait automatiquement : le développeur doit modifier son code pour cela.
Nouveautés de Python 3.2 : optimisations et verrou global (GIL)
L'algorithme de recherche de sous-chaîne est désormais utilisé par les méthodes replace(), split(), rsplit(), splitlines(), rfind(), rindex() et rpartition() des objets bytes, bytearray et str.
Le verrou global (GIL) a été réécrit pour avoir des intervalles d'échange de contexte plus prédictibles et limiter la contention du verrou. Par défaut, Python change de processus léger toutes les cinq millisecondes. Les performances de programmes utilisant plusieurs processus légers devraient être meilleures et plus fiables.
Le module « pickle » est beaucoup plus rapide : sérialisation jusqu'à 2× plus rapide et dé-sérialisation jusqu'à 10× plus rapide. De même, le module « json » a également été optimisé.
Les verrous récursifs (threading.RLock) ont été réimplémentés en C et sont entre 10 et 15× plus rapides.
Nouveautés de Python 3.2, en bref :
- la fonction builtin « callable() » avait disparu de Python 3.0 : elle fait son retour, car hasattr(obj, "call") n'est pas un remplaçant correct (il faut également tester cet attribut sur les classes parent) ;
- avec l'option « -Wdefault » en ligne de commande, Python émet un avertissement « ResourceWarning » si un fichier ou une socket n'est pas fermé explicitement (même quand le ramasse-miettes fait le ménage) ;
- Les modules « email » et « nntplib » ont été corrigés pour distinguer correctement octets et caractères, et donc éviter des erreurs de décodage des courriels ;
- Le nouveau décorateur « @functools.lru_cache » permet d'ajouter très facilement un cache de type Least Recently Used à vos fonctions ;
- Le module datetime gagne une implémentation concrète des fuseaux horaires : « datetime.timezone » permet de créer un objet fuseau horaire avec un décalage fixe par rapport à UTC (l'heure universelle) — ce qui est suffisant la plupart du temps. « timezone.utc » a été ajouté pour utiliser simplement UTC ;
- Le module shutil gagne des fonctions « make_archive() » et « unpack_archive() » pour gérer des archives (compression et décompression) dans différents formats (« .tar.gz », « .tar.bz2 », « .tar » et « .zip ») ;
- Le module html gagne une fonction « escape() » ;
- « ftplib.FTP », « tarfile.open », « socket.create_connection() », « tempfile.TemporaryDirectory() », « subprocess.Popen » et d'autres gèrent maintenant le protocole de gestion de contexte (mot clé « with ») ;
- Le module gzip gagne deux fonctions pour compresser et décompresser des chaînes d'octets en mémoire : « compress() » et « decompress() » ;
- Le module pydoc offre une meilleure présentation de la documentation, ajoute un outil de recherche rapide, et « pydoc -b » ouvre directement la documentation dans un navigateur web ;
- Le module abc gagne deux décorateurs : « @abc.abstractstaticmethod() » et « @abc.abstractclassmethod() » pour marquer une méthode abstraite comme étant statique ou une méthode de classe ;
- Python 3.2 gère mieux les chaînes d'octets non décodables depuis l'encodage de la « locale » du système. Le module os gagne l'objet « os.environb » pour lire les variables d'environnement sous forme d'octets, et non pas de chaînes Unicode comme avec « os.environ ».
Nouveautés de Python 3.2 : ce n'est pas fini !
La liste des changements est très longue. Je n'ai listé que les changements qui me semblent les plus intéressants et visibles. Je vous conseille vivement de lire le document « What's New In Python 3.2 » pour consulter la liste exhaustive des changements.
État du portage des modules vers Python 3
Tous les modules Python ne sont pas encore disponibles pour Python 3, mais il y en a de plus en plus. Il y a plus de 300 projets marqués comme compatibles avec Python 3 sur l'index des modules Python (PyPI). Parmi les modules les plus populaires disponibles pour Python 3 :
- Distribute : successeur de setuptools, sera remplacé à terme par distutils2 (lire The Hitchhiker’s Guide to Packaging pour en savoir plus) ;
- Jinja2 : moteur de template ;
- PyQt : binding de la célèbre bibliothèque Qt ;
- PyGObject : nouveau binding de Gtk+, encore un un peu jeune (incomplet), remplacera PyGtk à terme ;
- pygame : bibliothèque de création de jeux vidéo ;
- NumPy : calcul scientifique ; SciPy 0.9 sera aussi compatible Python 3, version qui devrait sortir très prochainement ;
- Sphinx : génération de documentation.
Voir aussi une liste plus exhaustive des modules disponibles pour Python 3.
Porter votre projet vers Python 3
Tutoriels et diverses informations pour porter votre projet vers Python 3 :
- HOWTO: Porting Python 2 Code to Python 3 ;
- Porting code to Python 3 ;
- Python 3: Beautiful, Explicit and Simple ;
- six : module facilitant l'écriture de projets compatibles Python 2 et 3 ;
- 2to3c : outil de conversion d'extensions C vers Python 3.
Et pour la suite…
De plus en plus de modules sont disponibles pour Python 3. Django, Zope et Pylons sont en cours de portage.
Python 3 commence à se généraliser dans les distributions GNU/Linux. Comme les développeurs Python ont abandonné la version 3.0 et que la 3.2 vient à peine de sortir, c'est donc naturellement Python 3.1 qui est utilisé pour le moment. État actuel :
- ArchLinux : utilise Python 3.1 comme interprète Python par défaut (commande « python », « python2 » lance Python 2) depuis octobre 2010 ;
- Ubuntu : Python 3 intégré depuis Intrepid ;
- Debian : Python 3.1 est entré dans Sid en janvier 2010 ;
- Fedora : depuis la version 13 ;
- Mandriva Linux : dans le dépôt « contrib », depuis 2010.0 ;
- Gentoo : Python 3.1 disponible.
L'édition 2011 de Pycon US se tiendra à Atlanta (Géorgie américaine) en mars. Python devrait migrer de Subversion à Mercurial à cette occasion, voire, si possible, juste avant. En France, Pycon FR n'a pas encore de lieu ou de date, mais est déjà prévu ; tenez-vous informé sur la liste de diffusion de l'Association Francophone Python (AFPy).
Tout est bon dans le Python !
Aller plus loin
- python.org (121 clics)
- What's New In Python 3.2 (212 clics)
- Documentation de Python 3.2 (101 clics)
- Python Developer's Guide (91 clics)
- Annonce de la sortie de la version 3.2 (27 clics)
# Encore bravo
Posté par 2PetitsVerres . Évalué à 9.
Merci patrick_g< pour cette dépêche sympathique et très agréable à lire.
;-)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Encore bravo
Posté par B16F4RV4RD1N . Évalué à 10.
haypo est à python ce que <s>pff est à apple</s> patrick_g est au noyau linux :)
(c'est triste les balises strike qui ne s'affichent pas...)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Encore bravo
Posté par boq . Évalué à 9.
Pourtant c'est facile le
bowlingmarkdown.~~strike~~[^] # Re: Encore bravo
Posté par erdnaxeli (site web personnel) . Évalué à 2.
C'est étonnant, ce marquage n'apparait pas dans la doc de markdown. Serait-ce un ajout de linuxfr ? (Par contre après lecture de la doc, markdown me plait beaucoup).
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: Encore bravo
Posté par B16F4RV4RD1N . Évalué à 8.
je dois avouer avoir plutôt markdown en horreur, mais les dégoûts et les couleurs, ça ne se discute pas... (j'avais proposé creole ou mieux, txt2tags qui est beaucoup plus complet, mais ça n'avait pas passionné les foules...)
Un des problème de markdown, c'est justement toutes les implémentations alternatives qui existent. Normalement markdown (officiel) permet les balises html pour rajouter ce qui n'existe pas comme syntaxe, mais ici <s> n'est pas pris en compte. Il y a bien markdown extra pour rajouter des fonctionnalités, comme on le voit ici : http://michelf.com/projects/php-markdown/extra/ Mais le tilde n'est pas présenté non plus dans markdown extra, aussi je ne vois pas d'où il est censé venir.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Encore bravo
Posté par patrick_g (site web personnel) . Évalué à 7.
Ce qui est un peu horripilant c'est le fait de devoir insérer des espaces en fin de ligne pour avoir un saut de ligne. AMHA il faudrait vraiment remplacer ça par un simple appui sur la touche "entrée".
[^] # Re: Encore bravo
Posté par boq . Évalué à 6.
Il vient de l'implémentation en C discount, repiqué de pandoc je pense.
DLFP utilise un wrapper ruby autour de discount plus quelques additions.
https://github.com/nono/linuxfr.org/blob/master/lib/lfmarkdown.rb
[^] # Re: Encore bravo
Posté par patrick_g (site web personnel) . Évalué à 10.
Ce n'est pas charitable de se moquer des pauvres travailleurs surmenés qui n'ont plus le temps d'écrire des dépêches :-)
Et bravo Victor pour cette excellente news !
[^] # Re: Encore bravo
Posté par Thomas Douillard . Évalué à 9.
Pas la peine d'essayer, de toute façon plus personne n'a d'avis :)
[^] # Re: Encore bravo
Posté par Diagonale de Cantor (site web personnel) . Évalué à -1.
Justement c'est l'occasion ou jamais de dire de la merde sans que son karma en prenne un coup ! Ça va troller sec cette semaine !
[^] # Re: Encore bravo
Posté par BAud (site web personnel) . Évalué à 4.
de l'avantage d'être modérateur :-) (mais oui relancer le script de réattribution d'avis, ce serait sympathique :D).
[^] # Re: Encore bravo
Posté par littlebreizhman . Évalué à 5.
C'est bon, il semble avoir été relancé... j'en ai
tropplein ![^] # Re: Encore bravo
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Je prends ça comme un compliment.
# État du portage des modules vers
Posté par boq . Évalué à 9.
Python 3 Wall of Shame
[^] # Re: État du portage des modules
Posté par Moonz . Évalué à 3.
À noter que markdown n’est même pas cité…
[^] # Re: État du portage des modules
Posté par Moonz . Évalué à 3.
On peut toujours pas modifier nos commentaires. Je voulais dire PIL, mais la nouvelle fenêtre de commentaires m’a perturbé ;)
[^] # Re: État du portage des modules
Posté par Albert_ . Évalué à 2.
Un peu obsolete le lien. Cela ne concerne que les applis portes sur python 3.0. D'ailleurs lorsque l'on regarde la liste on peut voir dedans sphinx et numpy qui sont annonce comme ok maintenant.
[^] # Re: État du portage des modules
Posté par DLFP est mort . Évalué à 2.
Ça me rassure (un peu). D'ailleurs setuptools est remplacé par distribute qui lui est compatible.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: État du portage des modules
Posté par boq . Évalué à 2.
C'est à jour (Updated: 2011-02-21) mais c'est généré automatiquement.
Apparemment il regarde dans les catégories si Python 3* existe.
Tout n'est pas exact mais ça doit quand même donner une bonne idée de la chose non? (vraie question en fait)
[^] # Re: État du portage des modules
Posté par Albert_ . Évalué à 2.
Je n'ai pas l'impression que cela donne une bonne idee vu que deux modules majeurs tel que numpy (calcul numerique), sphinx (documentation), virtualenv sont considere comme non compatible sur cette page.
L'automatisation c'est bien mais la en l'occurence cela ne marche pas a un niveau quelconque.
[^] # Re: État du portage des modules
Posté par tuxicoman (site web personnel) . Évalué à 0.
il manque wxpython aussi :-(
[^] # Re: État du portage des modules
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# Il faudrait...
Posté par kowalsky . Évalué à 10.
Il faudrait réécrire linuxfr en en python !
[^] # Re: Il faudrait...
Posté par El Titi . Évalué à 10.
Tu devrais proposer ça sur le suivi
[^] # Re: Il faudrait...
Posté par Nicolas Blanco (site web personnel) . Évalué à -10.
non
[^] # Re: Il faudrait...
Posté par Maclag . Évalué à 4.
Va falloir que ça bosse sévère chez les volontaires pour recoder Linuxfr à chaque sortie majeure d'un langage.
Qui se lance pour le recodage en OCaml?
[^] # Re: Il faudrait...
Posté par nicolas . Évalué à 5.
Tu voulais dire « à chaque sortie d’un langage majeur » ?
Exit OCaml donc.
…
Pourquoi le Ruby au fait ?
⇒[]
[^] # Re: Il faudrait...
Posté par erdnaxeli (site web personnel) . Évalué à 3.
OCaml c'est cool mais ... personne n'en fait. Et quand je dis personne ...
Du coup pour la doc c'est pas ça.
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
# Python dans Debian
Posté par tuxicoman (site web personnel) . Évalué à 4.
C'est bizarre dans Squeeze, il y a un paquet python 3.1. Vous êtes sur pour la date d'inclusion dans SID?
[^] # Re: Python dans Debian
Posté par Carl Chenet (site web personnel) . Évalué à 2.
Python 3.1.1 est rentré en Sid début 2010. Python 3.1.3 fin 2010. Par contre 3.2.1 est rentré hier dans Sid.
Pour plus d'infos : http://packages.qa.debian.org/p/python3.1.html ou http://packages.qa.debian.org/p/python3.2.html
[^] # Re: Python dans Debian
Posté par FlashCode (site web personnel, Mastodon) . Évalué à 1.
Donc il y a bien une erreur sur la date, c'est janvier 2010 et non 2011 pour Sid. Si quelqu'un peut corriger la news :)
WeeChat, the extensible chat client
[^] # Re: Python dans Debian
Posté par Victor STINNER (site web personnel) . Évalué à 2.
J'ai remonté l'info, ça a été corrigé.
# mode avocat du diable
Posté par palm123 (site web personnel) . Évalué à 2.
Python 3.x , c'est bien, mais qui "en production" utilise ces versions ?
Il me semble qu'aucun framework style Django ou Turbogears n'est disponible avec ces versions.
Et comme indiqué par un autre commentaire, il manque plein de modules.
ウィズコロナ
[^] # Re: mode avocat du diable
Posté par Antoine . Évalué à 4.
Il y a plus de 200000 téléchargements par mois rien que pour les installeurs Windows, je ne sais pas s'ils sont tous utilisés "en production" mais ça fait du monde.
Note: un langage de programmation ne sert pas qu'à faire tourner des frameworks Web.
[^] # Re: mode avocat du diable
Posté par lolop (site web personnel) . Évalué à 2.
En "prod" si on veut.
On l'utilise pour l'enseignement de base de la programmation en mesures physiques car il corrige des défauts de Python2 du genre 1/2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: mode avocat du diable
Posté par nicolas . Évalué à 2.
Humpf… Ne balance pas des trucs comme ça sans prévenir !
Tous les langages, à ma connaissance, donnent 0 pour « 1/2 ». Ce n’est aucunement un défaut : la division d’un entier par un autre s’entend comme une division euclidienne, dont le résultat est bien 0 dans ce cas-ci, c’est une des premières choses qu’on apprend en programmation : les types et leurs caractéristiques… Python est le seul qui va faire différemment. C’est justement une des « améliorations » très discutables. Et quand il s’agit d’un enseignement je n’ose imaginer les dégâts lorsque les élèves découvriront un vrai langage (c’est-à-dire tous les autres)…
Signé : un pythoneux qui va être très content de devoir vérifier tous ses scripts à cause de cette @*!`¶Þ de division.
[^] # Re: mode avocat du diable
Posté par feth . Évalué à 4.
Je comprends ton problème. Es-tu obligé de passer à Python3 ? Note : en Python3 la division entière est notée '//' :
% python3.2[^] # Re: mode avocat du diable
Posté par nicolas . Évalué à 1.
Pour l’instant non, mais il arrivera un moment où il faudra faire un choix entre passer à Python 3 ou ne pas avoir les dernières fonctionnalités. Pour l’instant j’ai cru comprendre que les nouveautés internes sont rétro-portées vers 2.7, mais j’utilise aussi beaucoup numpy et scipy, et je ne pense pas qu’ils vont s’amuser à maintenir deux versions en parallèle pendant longtemps : ce sont des extensions C et ça demande un peu de boulot, du peu que j’en ai vu, l’API C de Python n’est pas stable même entre version mineure (?).
Le problème est que je ne vois pas comment automatiser le passage de '/' à '//'. Comme on ne connaît pas le type d’une variable dans un code, on ne peut pas savoir, de manière automatique, si on a affaire à des entiers ou des flottants. Il faut donc revoir le code à la main. :'(
Dans la pratique, ça va être la méthode « à la r’hache » : passage à Python3, vérification rapide et exécution pour voir si ça casse quelque chose ou pas. \o/
[^] # Re: mode avocat du diable
Posté par claudex . Évalué à 6.
Et après les gens vont nous vendre qu'il n'y a pas de défaut au typage dynamique.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: mode avocat du diable
Posté par El Titi . Évalué à 5.
Et le TDD, c'est pas fait pour le chiens !
[^] # Re: mode avocat du diable
Posté par barmic . Évalué à 3.
L'analyse statique du code non plus.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mode avocat du diable
Posté par feth . Évalué à 2.
En même temps le typage dynamique n'a jamais interdit de faire des vérifications de type lorsqu'on les souhaite. Perso, que ma fonction
fonctionne avec un entier ou un flottant, ça m'arrange plutôt pas mal.[^] # Re: mode avocat du diable
Posté par barmic . Évalué à 4.
Pour ça qu'on a inventé la généricité ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mode avocat du diable
Posté par Antoine . Évalué à 4.
Les extensions C demandent très peu de boulot à porter (moins que le code Python).
Si, si.
[^] # Re: mode avocat du diable
Posté par Albert_ . Évalué à 2.
si tu utilises numpy tu peux utiliser dtype pour forcer le typage de tes arrays.
[^] # Re: mode avocat du diable
Posté par lolop (site web personnel) . Évalué à 5.
C'est un défaut pour des non informaticiens qui doivent apprendre juste à faire des petits scripts, et qui se retrouvent devant ce genre de comportement qui - même s'il a une explication informatique - n'est pas celui que le commun des gens s'attend à avoir.
Ta calculatrice, quand tu tapes 1/2, elle répond quoi ?
Et bien maintenant Python répond pareil. La division est une division "normale" que l'on a en maths, et si on veut une division entière on utilise le //.
Ceci dit, d'autres éléments comme le passage aux chaînes unicode sont un plus indéniable.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: mode avocat du diable
Posté par nicolas . Évalué à 6.
Non. En mathématique, si je travaille dans ℕ, je n’ai que la division euclidienne. La division telle que tu l’entends existe « à partir de » ℚ. Ma calculatrice travaille implicitement dans ℝ, mon ordinateur explicitement dans l’ensemble que je choisis (même si en Python cela est fait dynamiquement).
Bien sûr dans l’absolu on s’en tape un peu, il suffit de suivre une convention sur les symboles et de s’y tenir. Le problème est que pour le coup, Python3 ne suit pas la convention qui est établie depuis quelques décennies maintenant…
[^] # Re: mode avocat du diable
Posté par Yth (Mastodon) . Évalué à 1.
Et en C le problème ne se pose pas puisque les variables sont typées, donc si on a des int on a une division entière, des float une division réelle, et on fait des cast pour forcer la main.
Moi ça m'a toujours perturbé la division entière quand je tape 1/2 en python, et franchement, je préfère très nettement la syntaxe python 3, où on demande explicitement la division entière !
Par contre c'est clair qu'il va falloir faire une vérification sévère de code, parce que en python 2 on ne repère pas dans le code les endroits où il est important de faire une division entière, donc il faut analyser, comprendre, et choisir...
C'est à mon sens clairement un défaut de python qui est corrigé avec la nouvelle version !
Yth.
[^] # Re: mode avocat du diable
Posté par wilk . Évalué à 1.
Dans ce cas ça n'est pas des flottants qu'il faudrait utiliser mais des décimaux.
Ma calculatrice ne m'indique pas
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Certains processeurs IBM savent faire du calcul sur nombre flottant en base 10, comme les Power6 et Power7 : http://speleotrove.com/decimal/
Pour les pauvres, il y a le calcul en logiciel :
[^] # Re: mode avocat du diable
Posté par Antoine . Évalué à 2.
Python 3.2 a une représentation textuelle optimisée des nombres flottants :
(il est capable de choisir la représentation la plus courte qui soit suffisamment précise pour le nombre considéré)
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Effectivement, Python 2.7 également. Mais ça n'empêche pas d'avoir l'imprécision lié aux conversions entre les bases 2 et 10 à certains moments.
[^] # Re: mode avocat du diable
Posté par lolop (site web personnel) . Évalué à 3.
Prends l'habitude tout de suite...
de mémoire c'est quelque chose comme
Et après, tu as une division normale / et une division entière //.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Tous les langages, à ma connaissance, donnent 0 pour « 1/2 »
Donc tu considères, par exemple, qu'Octave n'est pas un langage ? :-)
Python est de plus en plus utilisé dans le milieu scientifique, notamment grâce à NumPy+SciPy, et 1/2 qui donne 0 fait un peu tâche.
Comme chaque changement majeur du langage, ce changement sur la division s'est fait via une demande d'amélioration de Python (PEP) : PEP 238: Changing the Division Operator. Cette PEP explique en détail pourquoi ce changement était nécessaire.
[^] # Re: mode avocat du diable
Posté par nicolas . Évalué à 2.
J’utilise Python dans un milieu scientifique. Et au contraire 1/2=0 ne fait pas tache. Tout les scientifiques sont habitués à la division entière, j’ai déjà expliqué au-dessus pourquoi. C’est un faux problème. C’est le niveau 0 de l’informatique numérique et c’est la première chose qu’on apprend aux étudiants.
« PEP 238: Changing the Division Operator »
Merci, il y a de bons arguments, et d’autres carrément mauvais, voir que je considère faux. Et si c’était à refaire je préfèrerais sans doute associer un symbole différent à la division entière/euclidienne.
Mais il fait l’erreur éternelle, la voie de la facilité : « But division poses a problem: if the expressions for both arguments happen to have an integral type, it implements floor division rather than true division. » Son raisonnement est celui-ci : 1/2 ne devrait pas être la troncature de la division des réels 1.0/2.0 donc il faut évaluer la division réelle (dans les deux sens du terme). Mais ici, il admet implicitement qu’il travaille avec des réels. Sa conclusion n’est pas une conclusion, mais son hypothèse de travail, car du moment qu’on parle de de division et de troncature, on parle de réels !
J’ai lu la suite du document, et leur histoire d’unification des types numériques me fait carrément peur. Pourquoi unifier ? Ce n’est pas le cas mathématiquement, un nombre entier a = 1, n’est pas le même objet qu’un nombre réel b = 1,0. Heureusement que Numpy, par la force des choses, continuera à permettre le choix du type. D’ailleurs je me demande comment Numpy pour Python3 implémente la division pour le coup.
[^] # Re: mode avocat du diable
Posté par barmic . Évalué à 1.
Octave c'est comme R c'est pas un langage généraliste, ça n'a pas l'ambition de faire tourner des sites webs, ni des applications graphiques, ça ne permet pas de faire du réseau (ou très peu juste pour ce connecter à une base de données).
Oui c'est possible de vouloir avoir un langage calculatrice (comme bc), mais aux dernières nouvelles l'ambition de python ne se limite pas à ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: mode avocat du diable
Posté par 태 (site web personnel) . Évalué à 8.
Lua est un vrai langage (qui fait tourner des sites webs, des applications graphiques et permet de faire du réseau ou de se connecter à une base de données). Et 1/2 y vaut 0.5.
C'est le langage sur lequel je me base pour apprendre l'algorithmique à des étudiants qui ne sont ni des informaticiens ni des mathématiciens (comme Laurent au dessus). Je l'ai choisi entre autres parce qu'il n'y a pas le piège des opérateurs qui ont plusieurs sens (j'évite aussi les questions de la concaténation avec +) qui pose de gros problèmes à ces étudiants. Cela dit, ils n'y couperont pas, il feront un jour du java et ils s'en plaindront, ça arrive juste plus tard.
[^] # Re: mode avocat du diable
Posté par djano . Évalué à -1.
Donc vous êtes en train de leur cacher les choses "difficiles" (bof, pas vraiment en fait) pour leur faciliter la vie? Ils vont passer tranquilles les premières années d'études avant d'arriver un jour sur de la récursion ou face a des pointeurs/références et la ils vont se demander pourquoi ils ont choisit de faire de la programmation, mais bon comme ils auront déjà passé 2, 3 ans dans le cursus ils ne vont pas s’arrêter pour autant et ils vont continuer jusqu'au bout.
Et puis ensuite une fois en entreprise, ils vont commencer a écrire du code dans lequel ils vont retrouver ces choses qu'ils n'ont pas compris et vont devoir travailler avec quand même. Et après on se demande pourquoi les logiciels ont pleins de bugs et pourquoi l'industrie informatique a des problèmes de qualité... Allez comprendre!
Oui, bien programmer n'est pas facile, oui les langages ont leur propre logique qu'il faut apprendre et maîtriser. Tant que les gens ne l'auront pas compris et ne l'accepteront pas, on ne va pas y arriver.
[^] # Re: mode avocat du diable
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
J'ai écrit du Python ces 9 derniers mois, professionnellement, et je n'ai pas le souvenir d'être tombé sur ça.
Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc. Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², j'étais bien persuadé que lors d'une division, l'inférence de type fonctionnait correctement.
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc.
Hum ? PHP distingue clairement 1 (type int) et 1.0 (type float).
Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², ...
Python 2 a deux types pour les nombres entiers : int et long. Avec Python 3, il n'y a plus qu'un seul type : int (qui est en fait le type long de Python 2). Je ne comprends pas ce que tu appelles "type numériqué" : un nombre entier ou flottant ?
[^] # Re: mode avocat du diable
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Certes, PḦP est une bouillie infâme au niveau des types
numériques.Un type numérique, c'est un type qui permet de représenter des nombres. En C les types numériques de base sont int, long, float, double et char. En PHP, effectivement, il y a int et float. Mais j'avoue que lorsque je pensais à l'expression « type numérique », je pensais à Javascript où seul le type numérique existe.
Les nombres flottant n'existent pas. float est un type numérique permettant de représenter de manière approximative les nombres réels. Mais en aucun cas on ne peut le considérer comme des nombres.
Bref, depuis j'ai testé quelques autres langages par curiosité. Avec CLisp, l'expression (/ 1 2) est évaluée à un demi, mais je ne connais pas assez LISP pour comprendre si CLisp retiens l'expression précise et attend pour évaluer par exemple. En Ruby, il faut qu'aussi bien le numérateur que le dénominateur soient un nombre décimal ou un flottant pour que l'expression soit évaluée à 0.5 (je ne connais pas le type par défaut utilisé pour stocker les nombres décimaux). Perl 5 évalue à 0.5 Bash évalue à 0, et ne comprends rien d'autre que les entiers. Lua évalue à 0.5.
Bref, voilà bien un détail à la con (ou gotcha) auquel il faut faire gaffe quand on apprend un nouveau langage.
[^] # Re: mode avocat du diable
Posté par Yth (Mastodon) . Évalué à 1.
En C :
r vaut 0.5 ...Mais c'est vrai que le C est un langage mineur... Ah, tiens, non en fait !
Mais oui, la division d'un entier par un entier est une division entière, c'est logique, même en C :
Et r vaut bien 0 !Mais en python, ou d'autres langages, 1, 2 doivent-ils forcément être entiers ? Ne devraient-ils pas l'être seulement quand on le veut ? C'est le problème du non-typage des données, 1 comme ça, ça peut être pas mal de choses, ça peut être un entier naturel, un relatif, un nombre rationnel, un nombre réel, un nombre complexe même.
Pourquoi serait-il plus logique que ça soit un relatif plutôt qu'un réel ? En python 2, pour obtenir 0.5, tu dois écrire :
Mais avec des variables manipulées à droite à gauche, sans que tu ne sois sûr du typage, comment tu forces une division réelle si x et y sont finalement des entiers, mais que ce que tu cherches c'est vraiment la division réelle ? Tu te fais chier. Alors qu'en python 3, si tu as besoin de la division entière, tu fais x//y, ça a du sens, dans un algorithme quelconque, chercher la division entière est quelque chose qui a du sens, un sens fort : ça change le résultat de l'opération. Ca me paraît très logique qu'on doive le spécifier de façon claire, au moins parce que le type des variable n'est pas lui spécifié, et que c'est une base du langage (à la différence du C, où cette question toute entière ne se pose en fait pas du tout).Yth.
[^] # Re: mode avocat du diable
Posté par nicolas . Évalué à 2.
Non en C, float r = 1/2 donne 0.f :
— évaluation de 1/2, les deux opérandes sont des entiers, pas de cast, on applique la division entière, qui donne 0 ;
— affectation à un float, on cast implicitement 0 en 0.f.
Comme je l’ai dit fondamentalement je suis d’accord, mais il y a la convention adoptée qui joue. Là Python, qui est typé, est juste en train de foutre le bazar en faisant les choses à sa sauce.
[^] # Re: mode avocat du diable
Posté par GeneralZod . Évalué à 2.
Mis à part Django qui n'est pas basé sur WSGI, le portage des frameworks web majeurs est tributaire de l'avancement du support de python3 par celui-ci. Le moins qu'on puisse dire est que ça traine depuis quelque temps et aucun consensus ne semble s'être fait. http://lucumr.pocoo.org/2010/5/25/wsgi-on-python-3/ http://wsgi.org/wsgi/Python_3
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Si tu vas lire le 2e lien de la dépêche, tu risques de tomber sur la section suivante en te faisant mal : PEP 3333: Python Web Server Gateway Interface v1.0.1.
Il y a eu des discussions houleuses au sujet de WSGI en Python 3, oui, mais un consensus a été trouvé : la PEP 3333 (WSGI "1.0.1") a été acceptée. Les modules cgi et wsgiref ont d'ailleurs été lourdement
corrigésaméliorés dans Python 3.2.WSGI 1.0.1 est un sale hack, ou "consensus" (pour être politiquement correct), pour offrir une meilleure compatibilité entre Python 2 et Python 3. La prochaine version de WSGI séparera correctement octets et caractères pour mieux exploiter les possibilités offertes par Python 3 avec sa dictinction entre les types bytes et str. Par contre, je n'ai pas assez suivi le sujet pour pouvoir donner des pointeurs pertinents vers la nouvelle version brouillon de WSGI. Il semble qu'il y ait plusieurs équipes qui se livrent une guéguerre en disant que leur WSGI 2.0 est mieux :-)
[^] # Re: mode avocat du diable
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Blender exige Python 3 depuis sa version 2.5. Eric 5 (IDE pour Python) est écrit en Python 3.
BIND 10, projet en cours de développement, peut être scripté en Python 3.
[^] # Re: mode avocat du diable
Posté par Gniarf . Évalué à 2.
ne nous plaignons pas, Blender pourrait également exiger LibreOffice.
# Unladen Swallow
Posté par djano . Évalué à 1.
Est-ce quelqu'un sait ou en est Unladen Swallow? Il n'y a eu aucun commit depuis le 21 août 2010. Est-ce que le projet est mort?
[^] # Re: Unladen Swallow
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Il existe une branche py3k-jit qui vise à intégrer le travail d'Unladen Swallow dans Python 3. Le dernier commit dans cette branche date de 8 mois, et c'était un merge.
Il existe aussi la PEP 3146: Merging Unladen Swallow into CPython.
Ça ne semble pas trop avancer...
Par contre, certaines optimisations faciles à intégrer font déjà parti de Python 3.2, je pense notamment à l'énorme optimisation de pickle citée dans la dépêche.
[^] # Re: Unladen Swallow
Posté par Philippe F (site web personnel) . Évalué à 4.
Pour unladen swallow, le projet est à l’arrêt depuis pratiquement un an. Les devs de google qui travaillaient dessus ont eu d'autres projets internes à gérer. Cela dit, ils disent qu'ils vont s'y remettre un jour, dès qu'ils ont le temps.
En attendant, PyPy commence enfin à donner des résultats digne de ce nom, donc ce sera peut-être lui le Python JITé qui référence.
[^] # Re: Unladen Swallow
Posté par djano . Évalué à 2.
Merci pour les réponses Victor et Philippe.
En effet, PyPy fait son bonhomme de chemin depuis un petit moment maintenant, et les résultats qu'ils obtiennent semblaient être autrement plus prometteurs que ceux d'Unladen Swallow (même si limités a du x86 32 bits). Les gars de Google étaient arrivé a grand renforts de communication, mais ils semblent s’être pris un mur avec un LLVM pas au niveau ou ils l'attendaient. Au final, pour ce qui est décrit dans le PEP 3146, les performances en temps CPU sont un peu meilleures, mais la consommation mémoire est bien moins bonne.
Alors du coup je me demande quel est l’intérêt d'intégrer LLVM a CPython puisque l'amélioration n'est clairement pas si fantastique que ça, et que les gars de Google ne bossent plus sur ce projet (qui vivra verra, mais ma petite expérience me fait dire que c'est mort).
[^] # Re: Unladen Swallow
Posté par Philippe F (site web personnel) . Évalué à 1.
Très clairement, en l'état, aucun. Il n'y a pas de mainteneurs de la branche unladen swallow, le port vers Python 2.7 ou 3.2 n'a pas été fait, et personne n'est là pour continuer à faire avancer le projet. Donc c'est pas prêt d'arriver tant que les deux ingénieurs de Google ne s'y remettent pas un brin !
# 2.7 = > 3.2
Posté par viicomte . Évalué à 1.
Voilà qui m'inciterait bien à changer ma version old-school 2.7 pour la 3.2 !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.