Python est un langage de programmation interprété multi-paradigme. L'interprète standard (CPython) est distribué sous licence PSF (semblable à la licence BSD). CPython est multiplateforme : Windows, Linux, Mac OS X, *BSD, AIX, MS-DOS, OS/2, QNX, etc.
CPython sert de référence pour le langage Python et les autres implémentations : PyPy (écrit en Python), IronPython (plateforme .NET) et Jython (JVM). Ces implémentations ne sont pas aussi à jour que CPython puisque IronPython est compatible avec Python 2.6 tandis que PyPy et Jython sont compatibles 2.5. Liste partielle des nouveautés issues de Python 3.1 :
- Syntaxe pour les ensembles littéraux : {1, 2, 3} au lieu de set((1, 2, 3))
- Compréhension de dictionnaire et d'ensemble, exemples : {i: i*2 for i in range(3)} (dictionnaire) et {i*2 for i in range(3)} (ensemble)
- Possibilité de spécifier plusieurs gestionnaires de contexte avec une seule déclaration with
- Réimplementation de la bibliothèque io (entrées/sorties) en C pour offrir de meilleures performances. Cette bibliothèque est notamment utile pour accéder à un fichier texte en Unicode.
- Dictionnaires ordonnés (enfin !) comme décrits dans la PEP 372 : from collections import OrderedDict
- La méthode format gère la numérotation automatique : '{} {}!'.format('Hello', 'World') donne 'Hello World'!
- Le formatage des nombres gère les séparateurs de milliers, exemple : '{:,}'.format(10800) donne '10,800'
- Amélioration de précision lors des conversions chaîne vers flottant et flottant vers chaîne. Pour un flottant, float(repr(x)) donnera toujours x.
- Nouveau module argparse pour parser la ligne de commande : version améliorée du module optparse
- Configuration basée sur des dictionnaires pour le module logging
- Objets memoryview : vue en lecture seule ou lecture-écriture d'un objet binaire (API similaire à celle du type bytes)
- Type PyCapsule pour l'API C (pour les modules d'extension)
- Les types int et long gagnent une méthode bit_length() : nombre de bits nécessaires pour représenter la valeur absolue du nombre
Lire What’s New in Python 2.7 pour de meilleures explications et la liste complète des changements.
Avertissements de dépréciation passés sous silence
Il a été décidé que les avertissements de type DeprecationWarning seront maintenant ignorés par défaut. C'est un changement par rapport à 2.6 qui les affiche (une seule fois pour chaque avertissement) par défaut. L'idée est d'éviter de polluer les utilisateurs avec des avertissements qui ne les concernent pas. Si un développeur veut les afficher, il peut ajouter l'option -Wdefault (ou la forme courte, -Wd) à Python, ou bien définir la variable d'environnement PYTHONWARNINGS à "default" (ou juste "d").
Python 3
Bien que Python 3.0 soit sorti peu après la version 2.6, et que la version 3.1 soit sortie entre temps, peu de développeurs ont sauté le pas. Cela s'explique par diverses raisons.
La première est que Python 3 n'apporte que peu de nouvelles fonctionnalités, mais impose de modifier le code source du projet (en plus des modifications de syntaxe réalisées automatiquement par l'outil 2to3).
La seconde est que toutes les bibliothèques majeures ne sont pas encore disponibles pour Python3. Exemple : PyQt l'est, alors que pygtk est uniquement compatible Python 2.
Enfin, du point de vue des développeurs de Python : il y avait deux branches dans lesquelles les nouvelles fonctionnalités étaient ajoutées (2.7 et 3.2), en plus des deux branches de maintenance (2.6 et 3.1). La plupart du temps, chaque commit devait être répliqué dans les 4 branches, ce qui a un coût non négligeable (bien qu'une partie soit automatisée) car le code de chaque branche a plus ou moins divergé (le pire étant les branches Python 2 et Python 3 justement).
Maintenant les nouvelles fonctionnalités seront développées uniquement dans Python 3. Les efforts vont donc se concentrer pour rendre cette branche plus attractive et aider au portage vers Python 3. Vous pouvez déjà consulter la liste des nouveautés de la branche 3.2 qui va grossir peu à peu.
Aller plus loin
- What’s New in Python 2.7 (35 clics)
- Télécharger Python 2.7 (141 clics)
- ChangeLog Python 2.7 (6 clics)
- Documentation de Python 2.7 (59 clics)
# PyGtk/Python3
Posté par GeneralZod . Évalué à 10.
https://bugzilla.gnome.org/show_bug.cgi?id=615872
https://bugzilla.gnome.org/show_bug.cgi?id=566641
[^] # Re: PyGtk/Python3
Posté par Xowap (site web personnel) . Évalué à 10.
[^] # Re: PyGtk/Python3
Posté par Corentin Chary (site web personnel) . Évalué à 4.
Mais bon, la diversité à du bon, tout ça ... C'est juste dommage qu'il n'y ai pas plus de sous derrière KDE.
[^] # Re: PyGtk/Python3
Posté par walken . Évalué à 5.
[^] # Re: PyGtk/Python3
Posté par zebra3 . Évalué à 3.
Alors que sous KDE, à part Oxygen, y'a quoi ? Plastik fait largement plus vieillot que Clearlooks, et il ne reste que CDE, Motif ou Windows 9x...
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: PyGtk/Python3
Posté par FreeB5D . Évalué à 5.
Il y a QtCurve, mais de toute façon il n'y a pas besoin d'autre thème qu'Oxygen, vu sa qualité : je regrette juste Baghira, mais il était de toute façon pénible à configurer (même avec le tuto sous les yeux) .
[^] # Re: PyGtk/Python3
Posté par FreeB5D . Évalué à 10.
C'est l'occasion de mettre à jour de KDE 3 vers KDE 4 .
[^] # Re: PyGtk/Python3
Posté par Skami_18 . Évalué à -5.
De plus, il y a dedans des choses très utiles comme GTKBuilder, que Qt n'as pas.
Après c'est sûr tout est relatif: une fois j'ai essayé pyQT4 et ça m'a franchement déplu...
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 7.
Hoo fud.
Qt a Qt Designer pour dessiner les fenêtres, et QUILoader pour charger les .ui dynamiquement.
http://doc.trolltech.com/4.6/quiloader.html
Au moins Qt a un bon support du buffer souris.
[^] # Re: PyGtk/Python3
Posté par GeneralZod . Évalué à 6.
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . Évalué à 1.
PyQt does not wrap the QUiLoader class but instead includes the uic Python module. Like QUiLoader this module can load .ui files to create a user interface dynamically
Bon, ok, on peut utiliser le module uic en lieu et place, mais je trouve cela bancal.
Aussi, je n'ai jamais réussit à enregistrer des "signals/slots" dans qt designer et à les connecter dans python comme je le ferais avec gtk/gtkbuilder/glade
Au moins Qt a un bon support du buffer souris.
Si tu parles du fait que l'event mouse-move est floodé sans moyen de contrôle, OUI, ce bug/feature me saoul particulièrement depuis un bout de temps.
Globalement je préfère gnome par rapport à kde, mais pour les applications graphiques que je développe, je m'en contrefout que cela soit du gtk ou du qt. Les éléments importants pour moi étant la simplicité de développement et la portabilité (+ facilité d'installation).
A l'époque ou j'avais fait du PyQT, je lui reprochais pleins de trucs, notamment :
- Une gestion de signal/slots dégueulasse avec PyQT. Je fais du python, je n'ai pas envi de déclarer des prototypes de fonction C++ au milieu de mon code python. Je crois que cela s'est largement amélioré depuis, mais je n'aime toujours pas.
- Ce problème de Uic cité avant
- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt. Gtk ne fait que le toolkit et le fait plutôt pas mal et je n'ai JAMAIS en plusieurs année de pygtk eu a jouer avec la glib.
- Le fait que cela soit un binding d'un truc en C++ fait avec sip. J'aime pas le C++ ;)
Par contre il est vrai que pyQt semble vraiment plus portable (par contre il semble que cela soit aussi la misère que pyGtk à installer sous windows), donc c'est un argument qui penchera en sa faveur le jour ou j'aurais un vrai besoin de multi-plateforme.
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 3.
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
- Le fait que Qt impose (c'est pas forcement vrai, mais c'est difficile de sortir du moule) vraiment la façon de penser Qt, l'utilisation de la lib Qt.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . Évalué à 3.
Ha ?
Non... Je parle de PyQT depuis le départ. Je n'ai jamais fait de C++Qt et je ne veut pas en faire (pour pleins de raisons, la première étant que je trouve stupide de s’embêter avec du C++ pour programmer, à mon humble avis, 99.9% des usages actuels du C++ sont non justifiés). La dépêche parlait de python, et ce fil de commentaire de PyQT/PyGTK, donc il n'y a pas trop de problème à ce que je parle de PyQT.
Je vois pas le problème dont tu parles avec les évènements pour le déplacement de la souris. Moi je parle de la sélection de texte et de ses intéractions foireuses avec le buffer souris sur Gtk : https://linuxfr.org//~mildred/29854.html
Ok. Personnellement cela ne m'a jamais posé problème, mais je me sert très peu de la souris. Ce qui me saoul ici avec Gtk c'est que lorsque l'on s’intéresse aux event souris, soit l'on en reçoit une quantité énorme non traitable en temps utile si le traitement prend un peu de temps (genre 100/s) si la souris bouge vite. Soit l'on peut activer le *buffer* (MOTION_HINT_NOTIFY) qui normalement se contente d'envoyer un seul event jusqu'à ce que tu lui dise qu'il peut en envoyer de nouveau, mais pourtant il continue à en envoyer plein.
Tout comme Gtk impose l'utilisation de la glib. Je vois pas le problème.
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Le binding pygtk est vraiment intégré de façon transparente à python. Apparemment c'est mieux pour le binding pyQT pour python3. En résumé je veux bien faire du QtGui, mais pas du QtList, QTString, QTFile, QtTortue.
Bref, quand python3 sera utilisable pour moi en production (mon attente principale étant numpy) et si quelqu'un me trouve comment faire pour connecter un signal de qt designer sur un slot de mon code, je redonnerais à pyqt sa chance. En attendant, pygtk est bien plus au dessus pour mon besoin à moins en confort de programmation.
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 1.
Alors n'affirme pas que Qt n'a pas d'équivalent à GTKBuilder, affirme que PyQt ne fait pas bien son boulot en choisissant de ne pas implémenter de bindings pour QUITools…
Avec pygtk je n'ai JAMAIS utilisé directement la glib. Je n'ai jamais utilisé la variante de string de la GLib, ni les structures de données de la Glib. A l'époque ou j'avais fais un peu de PyQT, je devais instancier des QString pour faire correctement fonctionner l'unicode et il m'arrivait de devoir charger des QList ou autre.
Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…
Sinon pour ton histoire de signaux et slots je vois pas non plus le problème…
Voici un exemple de code :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
app = QtGui.QApplication(sys.argv)
(f, c) = uic.loadUiType("test.ui")
class m(f, c):
def machin(self):
print "test !"
chose = m()
chose.setupUi(chose)
chose.show()
app.exec_()
Dans le fichier test.ui j'ai une fenêtre avec un slot machin() défini et connecté au clic sur un bouton… Et ça marche…
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . Évalué à 1.
Tu dois me confondre avec quelqu'un d'autre. Moi j'ai juste dis que le binding était pourris.
Merci pour le code. C'est bizarre (surtout le chose.setupUi(chose), cela me force à faire un héritage ce que je n'aime pas, mais cela à l'air de fonctionner.
Ce n'est plus le cas sur les dernières versions de PyQt, même en Python 2…
C'est pas ce que j'ai lu dans la doc. Mais cela ne m'empechera pas de restester le jour ou j'aurais à me poser la question (cf le message précedant ou je ne suis vraiment pas beliqueux envers pyQT, juste que à l'époque ou j'ai essayé, cela ne remplissait pas du tout mes besoins)
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . Évalué à 1.
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 3.
T'as alors une liste de slots avec un bouton + en dessous de la liste…
[^] # Re: PyGtk/Python3
Posté par claudex . Évalué à 2.
« 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: PyGtk/Python3
Posté par Pinaraf . Évalué à 2.
Effectivement, mea culpa…
Sinon pour le chose.setupUi(chose), c'est un choix dans mon implémentation…
J'aurais pu/du créer un QWidget à part et faire chose.setupUi(mon_beau_widget)
[^] # Re: PyGtk/Python3
Posté par Guillaum (site web personnel) . Évalué à 1.
Bon, ca marche bien. Faut que je trouve comment se debarasser de cet héritage que je n'apprécie pas trop, mais sinon cela marche bien.
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 2.
Lequel ?
Tu peux n'hériter que de QWidget par exemple et faire ceci :
#!/usr/bin/env python
# -*- coding: utf-8 -*-
from PyQt4 import uic, QtCore, QtGui
import sys
class myForm(QtGui.QWidget):
def machin(self):
print "test !"
app = QtGui.QApplication(sys.argv)
(uiForm, container) = uic.loadUiType("test.ui")
chose = myForm()
uiGenerator = uiForm()
uiGenerator.setupUi(chose)
chose.show()
app.exec_()
Je vois pas pourquoi l'héritage de QWidget serait un problème…
[^] # Re: PyGtk/Python3
Posté par Stibb . Évalué à 3.
- en tant qu'utilisateur : QT m'émerve, KDE est mal foutu, et ormis quelques applications, je ne les utilises plus. Trop complexes, mal foutu, moche, inutilisable, complexe. J'aime bien amarok, qtfps, smplayer. Chez moi tout le reste est en gtk. De manière générale, j'évite l'environnement KDE où je préfère la simplicité de gnome
- en tant que développeur : QT c'est le pied, la courbe d'apprentissage, la doc et le support sont extraordinaire, et je développe que des applications QT.
Mais alors pourquoi les developpeurs QT ont il tendance à faire toujours des soft trop complexes avec 15 000 panels de configuration, ... Et pourtant, c'est possible de faire de tres belles applications en QT... juste que les développeurs, quand ils voient la simplicité de programmation, compense par une complexité à l'utilisation...
Au final, je n'utilise que les applications qt qui sont en fait des GUI sur des programmes en ligne de commande.
[^] # Re: PyGtk/Python3
Posté par claudex . Évalué à 4.
Tu parles de Qt ou de KDE?
« 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: PyGtk/Python3
Posté par Stibb . Évalué à 3.
Il y a des applications QT extraordinaire (au niveau UI).
QT est vraiment le pied a programmer (en C++).
Il y a des applications GTK vraiment pourri (qui a dit GIMP?).
GTK est vraiment nul à programmer (en C++).
Mais de manière générale, sous leur environnement de prédilection respectif (KDE et Gnome), je trouve beaucoup plus agréable d'évoluer sous gnome que sous kde. Question de culture du nombre de bouton au metre carré je pense.
[^] # Re: PyGtk/Python3
Posté par LupusMic (site web personnel, Mastodon) . Évalué à -1.
Je n'aime pas KDE.
Qt ne se programme pas en C++. C'est du Qt C++, avec des gros morceaux de pré-processeur partout, et des classes doublons par rapport à la STL (j'en convient, il y a 10 ans il fallait bien proposer ces propres classes pour être portable. Il y a 10 ans).
Qu'est-ce qui te gêne dans Gtkmm ?
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 2.
Également, pour réaliser de l'introspection sans passer par le RTTI, le choix de moc me semble raisonnable.
Quand tu dis "gros morceaux de pré-processeur partout", je pense d'ailleurs que tu n'as pas vu de code en Qt depuis très longtemps...
[^] # Re: PyGtk/Python3
Posté par Stibb . Évalué à 2.
Quant au doublon avec la STL, si tu rajoutes boost, oui effectivement, ça fait VRAIMENT doublon.
N'empeche que de l'autre coté, gtk (en C) est vraiment une plaie à programmer. Je ne connais pas gtkmm... néanmoins il m'a l'air méchament lié ) automake, pkgconfig. Ca va pas facilité le portage sous windows ça...
Par contre... comment dire...
QT : http://doc.trolltech.com/4.6/classes.html
GTKmm : http://library.gnome.org/devel/gtkmm/unstable/group__Widgets(...)
hum, niveau doc... c'est pas trop ça.
[^] # Re: PyGtk/Python3
Posté par Pinaraf . Évalué à 2.
# Fonctionnalités Python 3.1 -> 2.7
Posté par Carl Chenet (site web personnel) . Évalué à 8.
Rien que ta liste partielle des nouveautés issues de Python 3.1 me donnerait envie de switcher si ce n'était déjà fait. À la fois du lourd comme les dictionnaire ordonnées et les compréhension de dictionnaire et ensemble mais aussi du sucre syntaxique qui fait la qualité de la syntaxe du langage Python
On remarquera également une participation importante de l'auteur de la dépêche à cette nouvelle mouture de Python en lisant le changelog ;)
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par bilboa . Évalué à 2.
Par contre la plupart des scripts existant sont en python 2 + flême et "ca marche pas mal déja", ca ca retarde l'adoption de python 3 chez moi :)
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . Évalué à 4.
Disclaimer : je ne suis pas un programmeur Python, donc je n'ai pas en tête les utilisations idiomatiques du langage.
Je ne comprends pas pourquoi cette fonctionnalité est mise en avant comme quelque chose de tellement bien. Pour moi, un dictionnaire ordonné c'est au mieux une curiosité qui sert une fois par an, au pire une API mutante qui encourage de mauvaises pratiques.
J'ai suivi le lien pour la PEP (merci pour le lien), et certaines des raisons qui sont données (paraphrasées selon ce que j'en comprends) me laissent un peu perplexe
- quand on manipule des noeuds XML, on veut stocker les attributs dans un dictionnaire, mais qu'ils restent dans l'ordre : il me semble que d'après la définition de XML, les attributs ne sont pas ordonnés, et qu'il est donc une mauvaise pratique de dépendre de l'ordre des attributs d'un document XML.
- on veut porter du code depuis PHP qui utilise implicitement le caractère ordonné du dictionnaire : est-ce que le code de départ avait vraiment besoin de l'ordre ? Je comprends l'intérêt de pouvoir porter du code même mal écrit, mais ça fait sourire d'apprendre qu'on va améliorer Python en facilitant l'import de code PHP douteux.
La PEP cite aussi deux exemples crédibles où une telle structure serait utile (les "struct" de C, dont le layout mémoire dépend de l'ordre, et à la rigueur les noms de colonnes SQL bien qu'on les manipule en général de façon non ordonnée).
Je ne pense pas que les dictionnaires ordonnés soient à bannir, mais je pense qu'ils ne sont en général pas nécessaires et qu'ils font souvent plus de mal que de bien (cf. l'exemple des attributs XML qui se contente de perpétuer de mauvaises pratiques). Les mettre dans la stdlib, pourquoi pas, mais je suis étonné de tout le bruit que ça fait, et de l'absence de mise en garde à ce sujet.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par sifu . Évalué à 3.
A chaque génération du XML, nous n'avions pas forcément le même XML. Peut-être que d'un point de vue sémantique, les XML étaient identiques mais pour valider les modifications, c'était toujours un peu la galère ...
Après, c'est peut-être aussi car je n'ai jamais trouvé un outils pour comparer deux XML correctement.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Thomas Douillard . Évalué à 1.
Dans les DTD tu pouvais décrire l'enchainement des sous balises, éventuellement mélangées à du texte, par une regex.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Thomas Douillard . Évalué à 0.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Carl Chenet (site web personnel) . Évalué à 1.
Tu peux très bien avoir besoin d'associer aux membres d'un dictionnaire une notion d'ordre sans vouloir passer par un conteneur ordonné classique (tuple, liste) qui va dénaturer ta structure de données en te forçant à utiliser un indice numérique par exemple.
Si ta remarque signifie "on pouvait s'en passer jusqu'à maintenant", personne ne te contredira. Maintenant l'inclusion de cette nouvelle structure de données te permet une plus grande liberté dans ton travail.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . Évalué à 3.
« Does OrderedDict support alternate sort orders such as alphabetical?
No. Those wanting different sort orders really need to be using another technique. The OrderedDict is all about recording insertion order. If any other order is of interest, then another structure (like an in-memory dbm) is likely a better fit. »
Je vois quelques cas où on a envie de donner un ordre sur les clés d'une table associative (typiquement, dans les langages où ces tables sont implémentées par des arbres équilibrés, l'implémentation demande déjà un ordre, et propose des fonctions d'itération qui garantissent de parcourir les éléments par ordre croissant des clés par exemple, et je m'en suis déjà servi dans de rares cas).
J'ai beaucoup plus de mal à trouver un bon exemple (qui soit naturel, et où ce n'est pas juste un hack) où l'ordre voulu est précisément l'ordre d'insertion des éléments. Je ne doute pas que ça existe, mais j'ai l'impression qu'il y a beaucoup de mauvais exemples et peu de bons exemples.
Qu'est-ce qui te fait dire que c'est "du lourd" ? Tu as des exemples intéressants à nous montrer où tu as senti le besoin de cette structure de données ? Je pense que ce serait une bonne idée d'agrémenter ce changelog un peu brut par une discussion réelle des fonctionnalités : comme je l'ai dit, je pense qu'il serait bon d'avertir les gens des risques de mauvaise utilisation (attributs XML), mais des bons exemples seraient encore plus sympas.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par djano . Évalué à 2.
Sorti de ce cas simple, je ne crois pas en avoir eu une vrais utilité ailleurs. Quelqu'un a d'autres exemples?
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Victor STINNER (site web personnel) . Évalué à 2.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par gasche . Évalué à 2.
Python 3.1.2 (r312:79147, Mar 21 2010, 18:30:25)[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import OrderedDict
>>> header = OrderedDict([('a', 'Nom de la colonne A'), ('b', 'Nom de la colonne B')])
>>> line = OrderedDict()
>>> line['b'] = 'Valeur pour B'
>>> line['a'] = 'Valeur pour A'
>>> for h in header.values(): print(h)
...
Nom de la colonne A
Nom de la colonne B
>>> for v in line.values(): print(v)
...
Valeur pour B
Valeur pour A
Il me semble qu'il faut repasser par un tri explicite des entrées du dictionnaire / de la liste, dans tous les cas.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Antoine . Évalué à 5.
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Par exemple : comprehensive list → Listes étendues/ensemblistes/complétives ?
(C'est quand même mieux que le troll à propos de Ruby ^^;)
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par Amand Tihon (site web personnel) . Évalué à 2.
[http://fr.wikipedia.org/wiki/Ensemble#D.C3.A9finition_d.E2.8(...)]
[^] # Re: Fonctionnalités Python 3.1 -> 2.7
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
# Scipy ?
Posté par mats . Évalué à 4.
l'un d'entre vous sait-il quand les bibliothèques de calcul numérique et de tracé seront utilisables avec python 3 ?
Sur le site de Scipy il est vaguement annoncé « milieu de l'année 2010 » sans plus de précision.
Bye
[^] # Re: Scipy ?
Posté par Nonolapéro . Évalué à 4.
Python 3 compatibility is planned and is currently technically feasible, since Numpy has been ported. However, since the Python 3 compatible Numpy 1.5 has not been released yet, support for Python 3 in Scipy is not yet included in Scipy 0.8. SciPy 0.9, planned for fall 2010, will very likely include experimental support for Python 3.
http://projects.scipy.org/scipy/roadmap#python-3
http://projects.scipy.org/numpy/roadmap
# microtrolloire
Posté par tyoup . Évalué à -5.
[^] # Re: microtrolloire
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: microtrolloire
Posté par claudex . Évalué à 3.
----> []
« 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: microtrolloire
Posté par nicolas . Évalué à 8.
[^] # Re: microtrolloire
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: microtrolloire
Posté par Joris Dedieu (site web personnel) . Évalué à -2.
C'est assez rigolo d'ailleurs vu que tout le monde ici utilise surtout perl ou php comme langage interprété.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
# D'ailleurs
Posté par vincent_k (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.