Guido Van Rossum donne comme raison pour ce moratoire les difficultés d'implémentation des versions alternatives de Python. CPython étant l'implémentation la plus répandue (standard de facto) et installée sur la plupart des distributions GNU/Linux actuelles, GvR parle de Jython, IronPython, PyPy et d'autres.
Le créateur du langage Python pense également que ce moratoire permettrait à Python 3.x de se diffuser plus largement qu'il ne l'est à l'heure actuelle.
Il est vrai que la transition de Python 2.x vers 3.x a été une source de perturbations importantes, 3.x cassant en effet la compatibilité avec la branche 2.x et 3.x est loin d'être aussi utilisée que la 2.x.
Debian ne travaille en ce moment qu'à la mise en place de Python 2.6 en tant que version par défaut de leurs systèmes. Cette proposition de Guido Van Rossum sera, si elle est acceptée, lourde de conséquences (bonnes ou mauvaises, l'avenir le dira) sur l'avenir du serpent le plus inventif qu'ait apprivoisé la communauté du libre depuis son commencement.
# Curieux les perturbations
Posté par reno . Évalué à 2.
En tout cas par rapport a Ruby 1.9, c'était l'impression que j'en avais..
[^] # Re: Curieux les perturbations
Posté par Albert_ . Évalué à 5.
Ce ne sont pas vraiment des details surtout sachant que par exemple la plupart des mac ont encore 2.5 ce qui fait que si tu veux faire un truc portable ben tu dois te limiter cette version.
[^] # Re: Curieux les perturbations
Posté par Victor STINNER (site web personnel) . Évalué à 8.
En d'autres termes, passer de la version 2.x à 2.x+1 prend trop de temps qu'on ne peut même pas encore envisager la migration à Python 3.1 (manque de main d'œuvre).
Au sujet de la migration des projets utilisant Python 2.x et voulant migrer à Python 3.x, il y a un outil de migration (2to3) qui permet de corriger la syntaxe. Par contre, le problème est plus au niveau des bibliothèques (PyQt, Twisted, Django, ...) qui migrent doucement vers Python3.
PS : Unladen Swallow est un fork de la version 2.6.1, donc pareil, pas de Python3 pour cette implémentation pour le moment.
[^] # Re: Curieux les perturbations
Posté par Albert_ . Évalué à -1.
Donc ca va pas etre tout de suite la migration vers 3.x en effet.
[^] # Re: Curieux les perturbations
Posté par riba . Évalué à 3.
matplotlib builde très bien sur python 2.6.1 et numpy 1.3. Je vois pas où t'as vu la limitation!
[^] # Re: Curieux les perturbations
Posté par Albert_ . Évalué à 1.
L'un n'exclut pas l'autre.
http://matplotlib.sourceforge.net/devel/coding_guide.html
Are your changes python2.4 compatible? We still support 2.4, so avoid features new to 2.5
[^] # Re: Curieux les perturbations
Posté par riba . Évalué à 2.
When committing changes to matplotlib, there are a few things to bear in mind.
- Are your changes python2.4 compatible? We still support 2.4, so avoid features new to 2.5
C'est pas parce qu'ils demandent aux développeurs de coder du python compatible 2.4 que matplotlib ne tourne pas sur 2.6!
Ta phrase était quelque peu ambigüe, et sous entendait que ça ne tournait que en 2.4.
[^] # Re: Curieux les perturbations
Posté par Albert_ . Évalué à 3.
[^] # Re: Curieux les perturbations
Posté par Albert_ . Évalué à 2.
Ils vont probablement passer directement a python3 mais bon vu l'apport pour les chaines de carecteres par exemple cela aurait ete pas mal un passage a 2.6.
[^] # Re: Curieux les perturbations
Posté par Maclag . Évalué à 2.
Après avoir vu des journaux expliquer que la 2.6 c'était pour préparer une migration en douceur, la sortie de la 3 a provoqué un déluge pour expliquer que ça allait tout casser les programmes actuels.
Et j'ai vu passer tout ça alors que je ne suis pas programmeur. C'est dire si ça a dû être répété...
[^] # Re: Curieux les perturbations
Posté par Antoine . Évalué à 3.
Ensuite, la version 2.6 rend la transition moins difficile, mais il n'est pas conseillé (sauf petits scripts) d'essayer d'écrire du code qui soit à la fois compatible 2.6 et 3.x. La méthode recommandée est d'utiliser l'outil "2to3".
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
# S'engager au freeze?
Posté par Crovax31 . Évalué à 2.
par exemple, je remplacerai bien les métaclasses par des décorateurs de classes pour montrer que c'est comparable à des décorateurs de fonctions...
Enfin pour ma part, si je ne balance pas ver 3.x de python, c'est pour deux raisons claire, en un le fait qu'on y perde en performance et en deux c'est que si c'est pour un site web héberger sur du mutualisé... bha c'est encore pas vraiment possible... mais tant que python 3 a des performances moindres que celles de 2.6 et qu'il n'a pas de vrai valeurs ajoutées... pas envisageable... il a aucune libs compatibles encore...
http://shootout.alioth.debian.org/u32q/benchmark.php?test=al(...)
[^] # Re: S'engager au freeze?
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Il ne s'agit que de figer le langage, la bibliothèque standard va continuer à évoluer, comme indiqué dans la dépêche.
je pense que la synthaxe reste perfectible
Les ajouts récents (with, décorateur de classe, etc.) sont du sucre syntaxique, càd qu'on peut s'en passer. Je pense que le noyau dur du langage (définition d'une fonction/classe, les modules, les boucles, les exceptions, etc.) est stable et cohérent, et qu'on devrait y survivre durant quelques années. S'il y avait des énormités insupportables, ils ont été corrigés ou alors ce n'était pas si insupportable que ça :-)
si je ne balance pas ver 3.x de python (...) qu'on y perde en performance
Unladen Swallow et PyPy ont un compilateur à la volée (JIT) qui montre de gros gains de performances, c'est très prometteur. Si Python2 devient 5x plus rapide mais que Python3 reste 30% plus lent que Python2, je pense que les 30% deviendront négligeables (ou dumoins, acceptables).
Petit à petit, les nouvelles fonctions et optimisations arrivent plutôt dans Python3 que dans Python2.
[^] # Re: S'engager au freeze?
Posté par Antoine . Évalué à 4.
Ah, tu veux améliaurer la synthaxe ?...
je remplacerai bien les métaclasses par des décorateurs de classes
Les décorateurs de classes existent déjà.
Ceci dit, des tas de gens ont des tas d'idées plus ou moins farfelues sur des façons de soi-disant "améliorer" Python, cela n'en fait pas des choses souhaitables. La liste "python-ideas" est chargée de propositions qui n'ont aucune chance d'aboutir, parce que mal pensées ou n'apportant aucune nouveauté réelle.
mais tant que python 3 a des performances moindres que celles de 2.6 et qu'il n'a pas de vrai valeurs ajoutées
Sur la performance, ça dépend des usages.
Sur la valeur ajoutée, rien que les chaînes de caractères unicode par défaut et la distinction stricte avec les chaînes 8 bits vaut le coup. C'est beaucoup plus utile que les décorateurs de classes...
[^] # Re: S'engager au freeze?
Posté par Crovax31 . Évalué à 1.
Les décorateurs de fonctions existent... j'avai lu un mail de refus de Mr python pour les décorateurs de classe (de 2004) mais effectivement en 2006 ça a été accepté...( http://mail.python.org/pipermail/python-dev/2006-March/06294(...) )
Du coup, effectivement le décorateur de classe est une nouveauté de python 3k :paf:, j'avai pas repéré ça dans le what's new...
Néanmois, je voix par exemple le C# qui est un langage qui bouge beaucoup... bon on a depuis longtemps la pluspart des fonctionnalités qu'ils ajoutent... (C#4 avec les paramètres nommés, le typage dynamique ^^...) ils ont des évolution de syntaxe comme leurs expressions lambdas, leur Linq qui sont potentiellement interessants...
C#: x=>x+2
Python: lambda x:x+2
enfin, dans la mesure du possible je préfaire développer en python, mais si une idée géniale survien, elle est limitée aux versions patché jusqu'à la levée du moratoire...
[^] # Re: S'engager au freeze?
Posté par Albert_ . Évalué à 3.
[^] # Re: S'engager au freeze?
Posté par Crovax31 . Évalué à 0.
Comme le dit Miguel lui même, si on voit mono comme une lib de compatibilité ce sera toujours à la traine mais c'est bien plus que ça, ça a beaucoup d'autres fonctionnalités que n'a pas .NET mais c'est vrai que leurs libs complémentaires tentant d'être compatibles .NET, il n'a de plus que certaines fonctionnalités pour le multitasking, le SIMD, le Csharp shell, la possibilité de faire un framework réduit sur mesure, les libs Iphone, des libs Terminal linux, une intégration DBus... mais a apporté à .NET par sa simple existance et ses choix de portabilité GTK#, {postgreSQL?}, des libs d'extentions, de gestion d'options de commandes, un annalyseur syntaxique, un IDE, libs ogg, libs de tags mp3, libs gecko....
Mais je suis d'accord mono est carrément à la traine derière .NET... ou pas tant que ça en fait... c'est juste des implémentations différentes...
[^] # Re: S'engager au freeze?
Posté par gallenza . Évalué à 1.
Franchement....
[^] # Re: S'engager au freeze?
Posté par Crovax31 . Évalué à 0.
Pour ma part, je trouve que mono est un projet interessant si ça ne t'interesse pas, je m'excuse d'avoir posté ce commentaire au grand maitre... je suis convaicu que tous les membres de linuxfr se désinteresse entièrement de mono...
Ou pas remarque c'est une technologie de développement opensource qui est très utilisée et qui fait beaucoup parler d'elle et qui attaqué injustement, et je trouvé cette réponse certes un peu capillo-tracté plus pertinante ici que dans un message privé.
[^] # Re: S'engager au freeze?
Posté par Albert_ . Évalué à 3.
Je suis ecroule de rire, franchement. Il doit y avoir une session lavage de cerveau sur Albert dans la secte Microsoft/C# c'est pas croyable.
L'exemple de C# est assez mauvais car le meme probleme existe vu que la seule autre version (mono) est a la bourre par rapport a la seul version officielle. Donc ca bouge et en dehors de l'implementation de reference l'autre rame derriere comme pour python.
Voir une attaque dans cette reponse cela me laisse perplexe.
[^] # Re: S'engager au freeze?
Posté par TImaniac (site web personnel) . Évalué à 3.
Albert croit qu'il compare la politique d'évolution de C# et de Python alors qu'en fait non il prenait juste un exemple de syntaxe sympa et indique que mono est, comme pour Python, toujours à la traîne, ce qui est vrai.
Crovax31 voit une attaque et rappelle que Mono n'est pas à la traîne sur les libs. Ce qui n'est pas faux, mais ne contredit en rien ce que dit Albert : mono est en retard en ce qui concerne le langage C# lui-même, ce qui est tout à fait vrai.
Tout le monde a raison \o/
[^] # Re: S'engager au freeze?
Posté par Crovax31 . Évalué à 1.
# différence entre dev et prod
Posté par palm123 (site web personnel) . Évalué à 1.
ウィズコロナ
[^] # Re: différence entre dev et prod
Posté par Crovax31 . Évalué à 1.
Celui qui decide au final c'est un noob qui connait rien à la vie d'entreprise... il est embauché par une petite boite qui a rien à faire de la fiabilité des technologies... Google...
:second degré:
Après les mail-lists publiques, tout le monde peut s'inscrire pour publier leurs idées, il n'y a forcément pas que des lumières...
Moi même il m'est arrivé de soumettre des suggestion sur un sujet que je maitrisait mal sur des mailing list de developpement...
Mais au final, ce n'est pas nécessairement représentatif de la fiabilité du logiciel final...
[^] # Re: différence entre dev et prod
Posté par Crovax31 . Évalué à -1.
[^] # Re: différence entre dev et prod
Posté par Crovax31 . Évalué à 1.
# Et sur debian ...
Posté par sifu . Évalué à 1.
J'ai vu que que la 2.6 et la 3 était disponible en expérimentale http://wiki.debian.org/Python3 .
Est-ce quelqu'un a déjà fait cohabiter ces versions ?
Je me disais que via update-alternatives cela devrait pouvoir se faire mais j'ai pas trouvé de trucs concluants.
Pour moi, c'est cela qui me gène le plus pour tester ...
Merci de vos retours.
[^] # Re: Et sur debian ...
Posté par Crovax31 . Évalué à 1.
pour ma part j'ai 2.5, 2.6 et 3.1 d'installés...
[^] # Re: Et sur debian ...
Posté par Anonyme . Évalué à 3.
Pour l'installation je n'ai rien de fait de spécial, il suffit d'installer les paquets.
J'ai également ajouté les lignes suivantes dans /etc/apt/preferences:
Package: python3.1 python3.1-minimal python3.1-doc python3.1-examples libpython3.1
Pin: release a=experimental
Pin-Priority: 990
Package: python2.6 python2.6-minimal python2.6-doc python2.6-examples libpython2.6
Pin: release a=experimental
Pin-Priority: 990
J'ai vérifié dans squeeze, il n'y a effectivement pas de règles update-alternatives associée à python. Il n'est de toute façon pas prudent de choisir une autre version que 2.5 en tant que version par défaut.
On se contente donc d'appeler explicitement la version voulue à partir des commandes python2.6 ou python3.1.
Dans un script il suffit de placer en première ligne un shebang du type:
#!/usr/bin/env python2.6
ou
#!/usr/bin/env python3.1
# Depuis le début
Posté par パパフラクス . Évalué à 8.
Bon, j'ai pas encore trouvé le langage idéal selon moi. Il y a des truc que je trouve moche dans Python, que j'aurai fait autrement, etc. Mais ce que je retiens, c'est que jusqu'à maintenant, chaque fois que j'ai ouvert un source Python, j'ai compris plutôt rapidement ce qu'il se passait à l'intérieur.
Et pour moi, c'est un avantage prépondérant qui me fera préférer ce langage à beaucoup d'autre. C'est vrai qu'en Java, c'est a peu près pareil, mais j'en bouffe toute la journée, donc ça compte pas, mon cerveau doit être trop déformé.
Cette lisibilité, on la doit au développeur d'abord, mais aussi au concepteur du langage, qui a toujours pesé le pour et le contre avec grand soin.
De plus je pense que Guido est un homme intelligent, il sait prendre son temps, et sais aussi changer d'avis, si on lui montre qu'il a tord, ça s'est déjà vu.
Bref, j'aime Python et j'ai entièrement confiance en Guido pour continuer à proposer un langage sans bloat, lisible, et qui continue d'évoluer. Peut-être moins sexy que son cousin Ruby, mais tellement efficace ;)
[^] # Re: Depuis le début
Posté par reno . Évalué à 4.
Comme c'est Vendredi, je vais repondre a cela: 'tellement efficace'?
Ruby et Python sont tous les deux tres lents.
'Moins sexy'?
A une epoque je voulais apprendre un nouveau langage de script (je n'aime pas le shell, je deteste le Perl) et j'avais regarde les 2: ma conclusion est que les deux etait vraiment tres, tres similaire en fait.
Mais depuis quand je vois les nombreux changement 'subtils' de Ruby 1.8 -> 1.9 et en comparaison le faible nombre de changement Python 2.x -> 3.x, je me demande si le choix de la simplicite pour Python n'est pas le bon choix plutot que d'avoir une syntaxe 'sexy' qui peut facilement se transformer en 'trop compliqué'..
[^] # Re: Depuis le début
Posté par wilk . Évalué à 1.
Le fait de geler le langage pendant quelque temps va permettre aux projets comme unladen swallow, pypy etc de devenir réellement viables et d'enterrer définitivement cette impression de lenteur qu'on peu parfois percevoir.
[^] # Re: Depuis le début
Posté par wilk . Évalué à 1.
http://code.google.com/p/unladen-swallow/wiki/Release2009Q3
* Unladen Swallow 2009Q3 uses up to 930% less memory than the 2009Q2 release.
* Execution performance has improved by 15-70%, depending on benchmark.
* Unladen Swallow 2009Q3 integrates with gdb 7.0 to better support debugging of JIT-compiled code.
* Unladen Swallow 2009Q3 integrates with OProfile 0.9.4 and later to provide seemless profiling across Python and C code, if configured with --with-oprofile=<oprofile-prefix>.
* Many bugs and restrictions in LLVM's JIT have been fixed. In particular, the 2009Q2 limitation of 16MB of machine code has been lifted.
* Unladen Swallow 2009Q3 passes the tests for all the third-party tools and libraries listed on the Testing page. Significantly for many projects, this includes compatibility with Twisted, Django, NumPy and Swig.
Et sur le blog de pypy les résultats annoncés sont pour le moins impressionnants...
http://morepypy.blogspot.com/
[^] # Re: Depuis le début
Posté par patrick_g (site web personnel) . Évalué à 2.
Heu comment c'est possible ça ?
[^] # Re: Depuis le début
Posté par Anonyme . Évalué à 2.
% = (M3-M2)/M2*100
M3 = mémoire utilisée dans la version 3
M2 = mémoire utilisée dans la version 2
Tout s'éclaire !
[^] # Re: Depuis le début
Posté par パパフラクス . Évalué à 5.
Quand je parlais d'efficacité, je parlais surtout en temps de développement, facilité de prise en main d'un code existant, etc.
Maintenant niveau perf, c'est largement suffisant pour ce que j'ai à faire. Dans certains cas, la vitesse peut être un critère, je ne le nie pas, mais j'ai l'impression que bien souvent, c'est plutôt un tic de geek, maniaque de la vitesse à tout prix.
Pour moi, si mon programme Python s'exécute en 0.4s, et qu'il m'a fallu 2 heures pour le développer, je suis largement plus satisfait que s'il s'execute en 0.05s, après 3 jour de dev en C.
Après, si des gens optimise encore l'interpréteur, ou fournisse un compilateur JIT, c'est tout bonus, je prend aussi ;)
Parfois j'aimerai bien faire mes petits dev en Haskell ou ocaml, mais bien souvent là aussi, le coté "Battery included" de Python fais pencher la balance
[^] # Re: Depuis le début
Posté par lolop (site web personnel) . Évalué à 10.
As-tu déjà essayé de ramper sur le ventre, sans t'aider des pieds et des mains ?
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.