Le développement de Python est ouvert et suit les propositions d'améliorations (PEP). L'outil de suivi de bugs (bugs.python.org) a migré de Sourceforge à une installation personnalisée de Roundup. La documentation LaTeX a été convertie dans le format reStructuredText et est maintenant compilée avec l'outil Sphinx, développé pour l'occasion. Améliorations du langage
- La PEP 3101 (Advanced String Formatting) révolutionne la manière de formater une chaîne de caractères. Exemples : "{0} {1}!".format("Hello", "World") ou "objet={obj}, taille={obj.taille}".format(obj=mon_objet). On peut réutiliser un argument plusieurs fois, changer l'ordre des arguments, lire un attribut d'un objet, lire un valeur dans un dictionnaire, etc.
- La PEP 3119 (Introducing Abstract Base Classes) permet de spécifier qu'une classe implémente une interface. Exemples d'ABC : Hashable, Iterator, Sized. Voir aussi la PEP 3141 (A Type Hierarchy for Numbers).
- Grâce à la PEP 3129 (Class Decorators), les décorateurs sont maintenant applicables aux classes.
- L'usage de with se généralise et est simplifié par la création du module contextmanager.
Nouveaux modules et nouvelles classes
- Le module multiprocessing est une réponse à la parallélisation massive des ordinateurs (processeurs multi-cœurs). Il permet d'exécuter une fonction dans plusieurs processus séparés de manière transparente. Rappel : à cause du Global Interpreter Lock (GIL), Python est incapable d'exécuter plusieurs threads en parallèle.
- Le module json gère la sérialisation d'objets dans le format JavaScript Object Notation (supporte l'import et l'export).
- Le module fractions contient la classe Fraction qui stocke la valeur exacte d'une fraction que les nombres flottants ne peuvent qu'approximer. D'ailleurs, le type float() supporte maintenant les valeurs « nan » (not an number), « +inf » et « -inf ».
Compatibilité avec Python3
Nombreuses fonctionnalités Python3 sont accessibles de manière optionnelles, par exemple par le module future_builtins :
- Avec « from __future__ import print_function », on peut utiliser print comme une simple fonction, alors que par défaut c'est un mot clé dans Python2. Exemple : print("Hello", "World", sep="_", end="!\n", file=sys.stdout) affiche « Hello_World! ». Lire la PEP 3105 (Make print a function).
- Les nombres peuvent être écrits directement en binaire. Le nouveau préfixe octal est « 0o ». Exemples : deux = 0b10 et dix=0o10. Lire la PEP 3127 (Integer Literal Support and Syntax).
- La PEP 3110 (Catching Exceptions in Python 3000) introduit une notation alternative pour les exceptions : « except (ValueError, TypeError) as err: ». Elle évite les erreurs du type « except ValueError, TypeError: ».
- Création du type bytes() qui est en fait un alias de str(). La PEP 3112 (Bytes literals in Python 3000) introduit les chaînes d'octets littérales : b'octets' est équivalent à 'octets'. Sauf avec « from __future__ import unicode_literals », dans quel cas les chaînes seront considérées de type unicode : 'unicode' vs b'octets').
- La PEP 3116 (New I/O) décrit le module io, la nouvelle bibliothèque d'entrée/sortie. Par défaut, c'est l'ancienne bibliothèque qui est utilisée. Utilisez par exemple io.open() pour accéder à vos fichiers textes en unicode.
Interprète Python
- Un utilisateur peut installer des modules Python dans son dossier personnel. Exemple : dossier « ~/.local/lib/python2.6/site-packages » dans le cas de Linux.
- Il est désormais possible de contrôler l'écriture des scripts Python compilés (.pyc et .pyo) avec l'option -B de Python et la variable d'environnement PYTHONDONTWRITEBYTECODE.
Faut-il migrer à Python3 ?
Python2 n'est pas près d'être remplacé par Python3. La migration se fera en douceur et progressivement.
Pour l'instant, il est recommandé d'écrire du code Python2 et le convertir avec l'outil 2to3 (intégré dans Python 2.6). En cas de problème, corriger le code original en évitant, dans la mesure du possible, d'introduire des tests sur le numéro de version.
Sachant que des projets ont mis plusieurs mois à migrer de Python 2.4 à Python 2.5, il y a peu de chance pour que les projets majeurs migrent complètement à Python3.
Python 2.7 est déjà prévu et améliorera encore la compatibilité entre Python2 et Python3. En attendant, Python 3.0 nous réserve encore quelques surprises (comme les arguments sous forme de mot clé uniquement, oups, ce n'est plus une surprise) !
Aller plus loin
- Python (8 clics)
- What’s New in Python 2.6 (9 clics)
- Propositions d'améliorations de Python (PEP) (3 clics)
- Générateur de documentation Sphinx (1 clic)
- Python sur dmoz (22 clics)
# dix???
Posté par case42 (site web personnel) . Évalué à 9.
heu... c'est pas plutôt huit=0o10 , ou j'ai rien compris?
[^] # Re: dix???
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: dix???
Posté par furai (site web personnel) . Évalué à 4.
[^] # Re: dix???
Posté par Édouard Siha . Évalué à 5.
[^] # Re: dix???
Posté par Archibald (site web personnel) . Évalué à 2.
[^] # Re: dix???
Posté par donkee . Évalué à 1.
dix=0o12
[^] # Re: dix???
Posté par freeze . Évalué à 2.
# GIL
Posté par jideel . Évalué à 2.
multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.
[^] # Re: GIL
Posté par Larry Cow . Évalué à 4.
Ou bien j'ai raté un truc?
[^] # Re: GIL
Posté par BAud (site web personnel) . Évalué à 3.
croire que tout le monde RTFA* ? :D
* en:RTFA tout en bas
[^] # Re: GIL
Posté par karteum59 . Évalué à 1.
Est-ce que qqun sait s'il y a une coopération avec le Python legacy ?
[^] # Re: GIL
Posté par Antoine . Évalué à 1.
[^] # Re: GIL
Posté par Antoine . Évalué à 1.
http://codespeak.net/py/dist/greenlet.html
[^] # Re: GIL
Posté par Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 2.
http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPytho(...)
[^] # Re: GIL
Posté par Gniarf . Évalué à 2.
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 3.
[^] # Re: GIL
Posté par Gniarf . Évalué à 7.
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: GIL
Posté par Gniarf . Évalué à 2.
mh là c'est toi l'expert, je ne pratiquais ni l'un ni l'autre.
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 2.
Tu sous-entends le contraire en mettant en doute les qualités de ces organismes en comparant le processus de normalisation d'un autre format qui a attiré les foudres de nombreux linuxiens.
Donc oui, soit t'es parano sur tout ce que normalise MS, soit tu cherches délibéremment à FUDer sans argumenter/détailler ta comparaison.
[^] # Re: GIL
Posté par abramov_MS . Évalué à 1.
1 - toute la partie non ouverte et couverte de brevet.
2 - Recemment il y a eu une interview du responsable de C# et .NET et il disait que la prochaine version serait peut etre normalise.
Et comme d'hab on va pas revenir sur le fait que l'implementation de mono a toujours une version de retard. Si l'on compare avec Java ou python c'est flagrant la difference de support sur les OS non microsoftiens... Mais c'est vrai c'est pas la faute de Microsoft ils ont que des incapables qui sont pas foutu de programmer sur un vrai OS (Je suis tres ironique naturellement et).
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 3.
Mon propos était justement de dire qu'IronPython ne dépendait pas de .NET. Enfin si un petit peu puisque son implémentation dépend de la partie DLR (Dynamic Language Runtime) non standardisé/normalisé... mais que Microsoft a mis sous licence libre.
IronPython marche sous linux aujourd'hui, c'est une réalité, pas la peine de troller sur .NET, c'est pas le propos.
[^] # Re: GIL
Posté par Gniarf . Évalué à 2.
donc bon ces organismes, niveau crédibilité, intégrité, tout ça, ça va plus.
ensuite tu me dis que l'ECMA me garantit des trucs, des espèces de droits, que je pourrais implémenter ces standards sans soucis et je devrais leur faire confiance ?
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 3.
Ok dérivons un peu.
L'ISO a perdu de la crédibilité de ton point de vue (et sans doute du point de vue de nombreuses personnes, surtout côté libristes), mais globalement il répond toujours aux attentes de ceux qui l'utilisent : un moyen pour les industriels de mettre en avant une norme pour des raisons purement commerciales (l'interopérabilité peut être un besoin commercial), je sais pas ce que s'imaginaient les bisounours libristes et le pourquoi de l'ODF à l'ISO.
Les votants "nationaux" ne sont là que pour protéger les intérêts de leurs industries respectives, d'où les "pressions" et autres "corruptions".
Bref l'ISO continue son petit bonhomme de chemin malgré la polémique.
Mais franchement dire que ce que garantie l'ECMA en terme de droits doit être mis en doute parcque l'ISO a normalisé un truc qui te plait pas, c'est du FUD pur et simple. Ou alors tu nous fait une belle démonstration argumentée qui prouve tes allégations (à savoir qu'on ne peut pas implémenter la CLR/CLI pour faire tourner IronPython).
[^] # Re: GIL
Posté par Victor STINNER (site web personnel) . Évalué à 4.
C'est une excellente chose qu'il existe différentes implémentations de Python. Si Microsoft (IronPython) ou Sun (Jython) sponsporise la sienne pour que Python s'intègre mieux à leurs environnement (resp. .NET et Java), je trouve ça bien. D'une manière ou d'une autre, ils contribuent à Python (ex: ça permet à plus de gens d'utiliser Python). Si la licence ne vous plait pas, passez-vous en ou recodez votre implémentation. Pour IronPython, je suppose que ça fonctionne sur Mono. Si ce n'est pas le cas, patchez Mono plutôt que de nous faire perdre du temps.
[^] # Re: GIL
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 2.
c'est même un des avantages avancés :
http://wiki.python.org/moin/IronPython
[^] # Re: GIL
Posté par abramov_MS . Évalué à 2.
http://www.jython.org/Project/
[^] # Re: GIL
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: GIL
Posté par abramov_MS . Évalué à 2.
# 2to3 … nostalgie … ou pas
Posté par Frédéric Heulin . Évalué à 3.
Je devrais aller prendre l'air moi je crois …
PS: Sinon pitié ramenez pas les 2be3 sous prétexte que ça ressemble plus hein.
[^] # Re: 2to3 … nostalgie … ou pas
Posté par Johan Charpentier (site web personnel) . Évalué à 1.
~~~"Partir un jour, sans retour"~~~>[- ]
# docs HS
Posté par Greg (site web personnel) . Évalué à 2.
Content de retrouver la doc, je commençais à ramer :)
[^] # Re: docs HS
Posté par Victor STINNER (site web personnel) . Évalué à 2.
# python 3.0
Posté par ribwund . Évalué à 2.
En effet c'est un énorme merdier la gestion des noms de fichiers. Étant donné que sous linux c'est fondamentalement des bytes, pourtant la plupart des fonctions os renvoient des strings (donc unicode). En fait actuellement c'est encore plus le bordel vu que ça peut renvoyer un mélange de bytes et de str. Par contre sous windows c'est de l'unicode derriere.
Franchement je vois pas quelle solution peut marcher, pour mercurial on a besoin d'avoir des listes de fichiers de façon indépendante de l'OS et du charset, c'est pas trop possible...
Voir http://bugs.python.org/issue3187 pour le bugreport.
[^] # Re: python 3.0
Posté par Victor STINNER (site web personnel) . Évalué à 4.
http://wiki.python.org/moin/Python3UnicodeDecodeError
En gros :
- Sous Windows n'utilisez que des chaînes Unicode
- Sous Linux et BSD (Mac OS X est un BSD) utilisez de l'Unicode si vous êtes fainéants (et vous avez raison ! « Sois fainéant, sois fainéant, tu vivras longtemps ! » chantait Coluche). Si vous voulez vraiment gérer les cas de merde (fichiers encodés n'importe comment, machine mal configurée), utilisez le type bytes (et des fonctions comme os.getcwdb()).
Pour info, svn refuse les fichiers dont le nom est encodé n'importe comment :
$ svn stat
(rien)
$ touch $(echo -e "oups\xff")
$ svn stat
(hex: 6f 75 70 73)
suivies par une séquence UTF-8 invalide
(hex: ff)
J'ai écrit un patch pour Python3 qui a été appliqué hier qui permet d'utiliser des noms de fichier sous forme de chaînes d'octets.
Finalement, Python3 simplifie le bordel car il passe TOUT en unicode (par défaut). Ce n'est que si vous voulez absolument gérer les cas de merde, que -comme dans tout langage- vous allez avoir des soucis en mélangeant octets et caractères.
http://www.paroles.net/chanson/22017.1
[^] # Re: python 3.0
Posté par ribwund . Évalué à 3.
Je pense quand même que le coup des bytes est par forcement une amélioration (surtout le fait de passer la gestion de fichier en unicode, je vois pas comment ça peut marcher sous Unix, sauf si on décide que tout le monde utilise UTF-8 en locale, et même comme ça ça doit être possible de créer un fichier qui fera planter python, ou mal fonctionner un programme parce que le dev aura pas pensé à ce cas particulier et utilisera l'API unicode), en pratique ça complique beaucoup le code pour nous (j'espere juste que ça s'améliorera).
Merci pour tes patches et ta volonté de faire avancer python sur ce problème.
[^] # Re: python 3.0
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Python2 et la grand majorité des langages de programmations n'utilisent que des octets, même s'ils nous mentent en utilisant des noms comme « char » (character) en C ou « str » (string) en Python. Bien qu'en Python2, on peut travailler en unicode, mais il faut le faire explicitement en utilisant le préfixe « u » (u'unicode').
En pratique pour les VCS et les outils de backup c'est la merde pour être multi-plateforme du coup.
Un outil de backup utilisera le type bytes sous Linux, et unicode (str) sous Windows. Les outils de backup représente qu'un faible pourcentage des applications. Les autres utiliseront unicode à tous les étages, ce qui simplifie énormément de choses (évite les horribles problèmes de mélange de charset).
sauf si on décide que tout le monde utilise UTF-8 en locale
C'est quand même de plus en plus le cas : UTF-8 est la locale par défaut sous Debian, Ubuntu, Mac OS X, etc.
Je pense qu'on préfère rester compatible avec les systèmes qui ne parlent pas correctement Unicode (autorisent les chaînes mal encodées) parce que c'est plus facile (zéro effort) que de corriger le problème à la source (d'où vient cette chaîne pourrie ?). Pourquoi ne pas renommer correctement le fichier une fois pour toute plutôt que de devoir corriger tous les programmes pour gérer ce cas pourri ?
[^] # Re: python 3.0
Posté par ribwund . Évalué à 3.
Sauf que dans ce cas c'est POSIX qu'il faut changer (rendre unicode obligatoire pour les noms de fichiers, et changer les systèmes de fichiers en conséquence), pour unix les noms de fichiers sont des octets.
Sinon à mon avis il faudrait unifier les deux API (win et linux) et par exemple toujours convertir les chaînes unicode en UTF-8 sous windows quand on utilise l'API bytes, ainsi le code pour open() sous windows décoderait à partir de l'utf-8 quand on lui passe des bytes.
[^] # Re: python 3.0
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Si tu veux polémiquer sur Python3, utilise plutôt la liste python-3000 et relit les long threads récent sur les noms de fichier unicode ou pas.
[^] # Re: python 3.0
Posté par freeze . Évalué à 1.
Où est le problème à avoir 2 versions ? Pour faire ça, les MFC (entre autres) permettent d'utiliser des LCHAR qui sont des char quand l'unicode n'est pas activé, et des wchar_t sinon.
Alors forcément, en python il n'y a pas de préprocesseur ... mais bon, il doit bien y avoir une solution, non ?
[^] # Re: python 3.0
Posté par Antoine . Évalué à 1.
On n'oblige pas les gens à utiliser ça. Quand tu demandes un nom de fichier unicode sur un système Posix, des heuristiques sont utilisées pour découvrir le jeu de caractères en vigueur sur le système. Le problème c'est qu'en pratique chaque filesystem peut avoir un jeu de caractères différent...
Où est le problème à avoir 2 versions ?
Le problème c'est que ça t'oblige à avoir deux chemins de code différents dans ton application, selon que le nom de fichier est unicode ou 8 bits. Alors que ce serait beaucoup mieux si la couche IO de la stdlib s'en chargeait.
[^] # Re: python 3.0
Posté par ribwund . Évalué à 2.
Même chaque fichier, un cas très courant c'est 2 utilisateurs sur un même filsystem avec des locales différentes.
[^] # Re: python 3.0
Posté par benoar . Évalué à 3.
[^] # Re: python 3.0
Posté par ribwund . Évalué à 1.
[^] # Re: python 3.0
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.