Pensez-vous que Python 3.x était une erreur ?

Version imprimable

18/02/2015, 00h50
Olivier Famien

5 pièce(s) jointe(s)

Pensez-vous que Python 3.x était une erreur ?

Pensez-vous que Python 3.x était une erreur ?
54 % de développeurs estiment qu’il fallait une étape de transition

Python, qui est un langage de programmation très apprécié des développeurs, suscite depuis sa version 3.x de vifs débats dans le monde informatique. Et pour cause ; l’implémentation de sa version 3.x rompt en terme de compatibilité avec les précédentes versions 2.x et inférieures.

Dans les faits, plusieurs corrections ont été apportées au langage avec la version 3.x. À partir de cette version, l’interpréteur de la version 3.x génère des erreurs lorsqu’il doit exécuter du code écrit avec la version 2.x. Cette rupture factuelle a eu pour conséquence immédiate d’inciter certains développeurs à abandonner la version 2.x pour la nouvelle itération. D’autres par contre préfèrent pour une raison ou une autre continuer de travailler sous la version 2.x.

Aussi, pour mieux comprendre les raisons profondes des défenseurs et pourfendeurs de chaque version, une étude a été menée sur l’année 2013 et reconduite en 2014.

6752 personnes ont été interrogées en 2014. Les résultats obtenus ont été en partie comparés à ceux de l’année 2013 et pour d’autres exposés directement. Dix points ont été abordés dans l’étude. En voici un extrait.

1. Avez-vous déjà écrit du code avec python 2.x ou 3.x

http://www.developpez.com/public/ima...on-survey1.jpg

Interprétation :
- python 2.x : en 2013 comme 2014, 97 % des personnes interrogées ont écrit du code
- Python 3.x : en 2013, 60 % des interrogées ont écrit du code avec cette version. En 2014, nous avons eu une progression de 12 %.

2. Avec quelle version de python écrivez-vous présentement (2014) du code : 2.x ou 3.x

http://www.developpez.com/public/ima...on-survey2.jpg

Interprétation :
- python 2.x : en 2013, 78 % des sondées écrivaient du code python avec cette version. Une baisse de 10 % a été observée en 2014 pour cette même version.
- Python 3.x : en 2013, 22 % des interrogées écrivaient du code avec la version 3.x. En 2014, nous avons eu une progression de 10 %.

3. Lorsque vous commencez un projet personnel, quelle version utilisez-vous ?

http://www.developpez.com/public/ima...on-survey3.jpg

Interprétation :
- 50 % des interrogées en 2014 débutaient leur projet personnel avec python 2.x contre 50 % pour ceux utilisant la version 3.x

4. Quelle version de python utilisez-vous régulièrement ?

http://www.developpez.com/public/ima...on-survey4.jpg

Interprétation :
- Python 3.4 : 43 % des interrogées écrivaient régulièrement du code en 2014 avec cette version.
- Python 2.7 : 81 % des interrogées utilisaient régulièrement cette version en 2014 pour écrire du code en 2014.

5. Pensez-vous que Python 3.x était une erreur ?

http://www.developpez.com/public/ima...on-survey5.jpg

Interprétation :
- 12 % des interrogées en 2014 pensent que python 3.x était une erreur.
- 34 % des interrogées en 2014 pensent le contraire.
- 54 % estiment qu’il fallait une étape de transition.

D’autres visuels sont disponibles à cette page. Pour une analyse complète des résultats de l'étude, vous pouvez également consulter cette page.

Source : Blog Randy Oslon

Et vous ?

:fleche: Que pensez-vous des résultats de cette étude ? Les trouvez-vous pertinents ?

:fleche: Quelle version de python préférez-vous ? Pourquoi avez-vous opté pour cette version ?
18/02/2015, 08h07
tyrtamos

Bonjour,

Citation:

Envoyé par Olivier Famien

:fleche: Que pensez-vous des résultats de cette étude ? Les trouvez-vous pertinents ?

On peut discuter pendant longtemps de ce qu'il aurait fallu faire lors du lancement de Python 3, mais pour moi, ça n'a qu'un intérêt limité. On peut toujours regretter qu'une transition plus douce n'ait pas été choisie, mais je ne suis pas sûr qu'elle aurait été techniquement possible, ni qu'elle aurait eu moins de conséquences sur les codes.

Citation:

Envoyé par Olivier Famien

:fleche: Quelle version de python préférez-vous ? Pourquoi avez-vous opté pour cette version ?

Je suis passé à Python 3 en 2014: ça m'a consommé pas mal de temps, mais j'en suis ravi: la rupture partielle de compatibilité a permis de résoudre plein de problèmes irritants de Python 2, à commencer par les encodages.

Et puis le petit code "2to3" permet d'alléger cette conversion, même si elle ne résout pas tous les problèmes. Par exemple, pour moi qui travaille avec PyQt4, il y a des modifications spécifiques qui ne sont pas traitées. Et avec Python 2, je ne pourrais pas passer à PyQt5 (qui oblige Python 3).

La seule chose qui me gène vraiment, c'est le retard de certains fournisseurs. Il était prévu 5 ans de transition pour passer à Python 3, et nous les avons maintenant largement dépassés.
Malgré cela, je constate:
- que les Python installés par défaut sur les "Unix" (Linux et Mac OS X) en sont encore à Python 2
- que mon hébergeur web chez lequel j'ai une application Python qui tourne en CGI en est encore à Python 2.5, ce qui m'oblige à gérer le même code dans les 2 versions.
- que certains modules externes ont encore du mal à passer à Python 3, et que certains risquent d'en mourir...

Bref, Python 3 existe, et continue à progresser (3.3, 3.4, 3.5, ...): ce serait vraiment dommage d'en rester à Python 2 dans les prochaines années...
18/02/2015, 11h17
mangobango

Rien que pour la gestion de l'Unicode, Python 3 valait le coup :)

Bon, perso j'ai l'analyse inverse (pour changer). Il a manqué -à mon humble avis- d'incitations à passer à Python 3. En prolongeant la durée de vie de Python 2.x, cela a encouragé à se recroqueviller dans la zone de confort que représentait Python 2.x. En intégrant des rétro-portages de fonctionnalités de la 3.x vers la 2.x on n'a pas créé une rupture propre, en permettant aux plus frileux de se rabattre encore une fois sur la 2.x (beaucoup de libs utilisant du code compatible avec les deux versions) plutôt que d'embrasser pleinement la 3.x.

Mais peut-être que sans cette transition - trop douce à mon goût - Python 3 n'aurait jamais pris :)

Daniel
18/02/2015, 12h30
earhater

Il est vrai que ce qui tue le langage c'est qu'on l'a en double ... Peut être une étape de transition puis l'abandon de python 2.x ?
18/02/2015, 14h03
yahiko

S'il y a bien une chose de pénible avec Python c'est bien ces histoires de non rétrocompatibilité entre les versions majeures (2.x vs 1.x et maintenant 3.x vs 2.x).

Ce n'est peut-être pas si grave en milieu éducatif et universitaire, mais ce genre de gouvernance est prohibitif pour les entreprises et fait perdre à Python le crédit qu'il pourrait pourtant avoir si les évolutions étaient plus respectueuses de l'existant.
18/02/2015, 14h05
Theta

Il est vrai que ces deux versions utilisées en parallèle causent du tort au langage. Pas mal de ressources n'ont pas fait le passage à la version 3 du coup ça peut inciter des dev à rester sur la version 2, et donc retarder encore la disparition de la version 2, c'est un cercle vicieux.

Cela dit je préfère encore ça aux langages qui sous couvert de rétro-compatibilité gardent ad-vitam des comportements inélégants.
18/02/2015, 14h10
yahiko

Citation:

Envoyé par Theta

Il est vrai que ces deux versions utilisées en parallèle causent du tort au langage. Pas mal de ressources n'ont pas fait le passage à la version 3 du coup ça peut inciter des dev à rester sur la version 2, et donc retarder encore la disparition de la version 2, c'est un cercle vicieux.

Cela dit je préfère encore ça aux langages qui sous couvert de rétro-compatibilité gardent ad-vitam des comportements inélégants.

Au pire, il y a toujours la possibilité de créer un nouveau langage sans pour autant pousser une communauté à abandonner un langage en place et qui pourrait évoluer autrement.

Non, vraiment, cette façon de faire table rase à chaque version majeure fait que Python ne sera jamais pris sérieusement dans le monde professionnel.
18/02/2015, 14h18
mangobango

Citation:

Envoyé par yahiko

S'il y a bien une chose de pénible avec Python c'est bien ces histoires de non rétrocompatibilité entre les versions majeures (2.x vs 1.x et maintenant 3.x vs 2.x).

Ce n'est peut-être pas si grave en milieu éducatif et universitaire, mais ce genre de gouvernance est prohibitif pour les entreprises et fait perdre à Python le crédit qu'il pourrait pourtant avoir si les évolutions étaient plus respectueuses de l'existant.

J'étais pas très actif en Python à l'époque de la transition 1.x vers 2.x. C'était quoi les points d'accroche à l'époque?

EDIT: Ah si, il y a un truc qui m'a bien agacé avec les différentes versions de Python, mais ce n'est pas spécifique à la transition 2.x -> 3.x, c'est les changements au niveau de l'API C qui nécessite de recompiler les extensions C à chaque version ou presque. A un point j'ai préféré écrire une API C à mes codes C/C++ (indépendante de Python.h), compiler en *.so/*.dll et taper dedans avec ctypes... Bourrin.

Daniel
18/02/2015, 15h37
Traroth2

si le sujet est la rupture de compatibilité, je ne vois pas trop ce qu'une étape de transition aurait changé...
18/02/2015, 17h29
robertledoux

Python aurait pu être quelque chose de fantastique, mais malheureusement, la fainéantise légendaire des dev. python (Il n'y a qu'a voir le nombre d'extension ou pour le moindre patch ou évolution, le mec te demande de le faire toi même). résultat, on se retrouve avec une version 3 forkée depuis la branche 2.7 qui est moisie jusqu’à l'os.

Sans déconner, les mecs avait l'occasion de repartir depuis zéro avec une véritable API (l'API C actuelle pour embedded Python est juste dégueulasse), une gestion des threads correcte, retirer le GIL et surtout avoir un code propre, une architecture claire et modulaire. Mais non il on juste forké la 2.7 qui est une m**** sans nom.

Python pour moi est mort depuis des années.
18/02/2015, 18h03
Thorna

De la fiabilité de ce genre de sondage...

En sous-titre de l'article :

Citation:

54 % de développeurs estiment qu’il fallait une étape de transition

En résultat (provisoire) du sondage :

Citation:

6,25% des répondants pensent qu'il fallait une version de transition

Bien sûr, le nombre de réponses n'est pas identique dans les 2 cas (6000 et quelques contre moins de 20 mais ça ne se voit pas !), mais le résultat est suffisamment différent pour qu'on puisse conclure qu'on ne peut rien conclure, sans d'avantage de précisions !
- Comment ont été interrogées les 6700 personnes ? Comment ont-elles été choisies ?
- Comment répondent les gens ici ? Selon quels critères ?
Outre le sujet lui-même, dont le contenu est très intéressant, l'intérêt ou la fiabilité des résultats d'un tel type de sondage semblent à prendre réellement avec des pincettes...

Citation:

Envoyé par yahiko

Non, vraiment, cette façon de faire table rase à chaque version majeure fait que Python ne sera jamais pris sérieusement dans le monde professionnel.

Ha ha ha !
18/02/2015, 20h20
mothsART

changement nécessaire

Changer d'API n'est jamais un choix simple et je trouve que la transition à été dans l'ensemble plutôt bien négocié.
Traroth2 le dit bien : difficile de faire plus doux quand on casse tout.

Savoir abandonner des vieilleries et faire le pas sur du neuf est gage de sérieux, non?

En plus, python c'est l'adage "only one way to do it" donc incompatible avec des anciennes et des nouvelles façon de faire.
J'estime qu'un dev actuel n'est pas isolé, il doit régulièrement comprendre et retoucher le code d'un tiers...
Pour ce faire, une API concise est source de productivité! Quand je vois l'évolution de C++, qui garde tout, et qui s'enterre vivant...

Après, d'autres langages, comme PHP en sont déjà à la version 5 (en 2040, il passeront peut-être la 6 qui manque cruellement) et que la communauté autours ne s'évapore pas pour autant, je ne vois vraiment pas le soucis.

Enfin, je comprend "robertledoux" sur son mécontentement. Maintenant, je pense que les core-devs ont du faire des choix pragmatiques.
Réécrire from scratch 20 ans de dev, c'est pas une mince affaire.
Les threads sont remplacés par du multi-processing lorsqu'il y a un vrai besoin de paralléliser. Pour les puristes, ça peut paraître crade mais dans 95% des cas, ça reste acceptable.
Je persiste à dire que les soucis de verrou globale du GIL n'est pas si pénalisant qu'il n'y parait.

Enfin, Cpython, même si il reste l'implémentation de "référence", est loin d'être le seul interpréteur. Pypy, par exemple, est beaucoup plus propre, utilise du JIT, n'a pas de GIL, fait du sandboxing, dispose de plusieurs type de Garbage collector etc.

A mon sens, les soucis inhérent à Cpython dont tu parles sont difficile à régler justement en C.
Il faudrait un vrai langage taillé pour la concurrence : pourquoi pas Rust (une fois stable)?
18/02/2015, 22h23
mangobango

Citation:

Envoyé par robertledoux

Python aurait pu être quelque chose de fantastique, mais malheureusement, la fainéantise légendaire des dev. python (Il n'y a qu'a voir le nombre d'extension ou pour le moindre patch ou évolution, le mec te demande de le faire toi même). résultat, on se retrouve avec une version 3 forkée depuis la branche 2.7 qui est moisie jusqu’à l'os.

Sans déconner, les mecs avait l'occasion de repartir depuis zéro avec une véritable API (l'API C actuelle pour embedded Python est juste dégueulasse), une gestion des threads correcte, retirer le GIL et surtout avoir un code propre, une architecture claire et modulaire. Mais non il on juste forké la 2.7 qui est une m**** sans nom.

Python pour moi est mort depuis des années.

(:mrgreen: On dirait moi quand je peste contre javascript que je voudrais voir disparaître de la surface de la Terre :) )

C'est vrai que de nous avoir refilé le GIL pour encore quelques décennies c'était pas vraiment sympa. C'est une plaie ce truc.

Daniel
19/02/2015, 10h19
keunene

j'avais débuté avec python, mais les deux versions incompatibles m'ont troublé et donc j'ai dû l'abandonner.
19/02/2015, 13h16
tyrtamos

Bonjour,

J'avoue que je suis très étonné par les réactions violentes de certains concernant ce passage à Python 3.

Ce n'est pas un problème si gros qu'il entraine l'abandon du langage! L'utilisation du petit script "2to3" permet de déblayer 90% des modifs, et les 10% qui restent sont faciles à faire (un logiciel de type "recherche et remplacement multi-fichiers" est une aide intéressante).

En contrepartie de ce petit travail, Python 3 a fait beaucoup de progrès sur de nombreux sujets, ce qui rend les développements suivants plus faciles. La quantité de modules d’extension est extrêmement grande dans de très nombreux domaines. Pour ma part, je fais beaucoup de graphiques (PyQt4) en multiplateforme, et les programmes obtenus sont beaux et rapides au point que les utilisateurs ne savent pas que c'est du Python. Et il est toujours possible de développer un module en C ou C++ pour les parties critiques.

Je suis aussi surpris par certaines remarques. Les threads ne fonctionneraient pas? Ah bon? Pourtant, je les utilise couramment et sans problème dans les 2 versions de Python depuis des années.

Je ne suis pas "marié" avec Python, et je regarde périodiquement l'offre des principaux langages (hors C et C++): je n'en vois pas beaucoup d'autres qui soient en même temps aussi complets ni aussi pratiques en facilité de développement.

(non: ce n'est pas un troll! :D)
19/02/2015, 13h58
esperanto

Comparaison

Je ne progamme pas en Python mais en Perl. J'écris ici pour apporter au débat un point de comparaison extérieur.

Je reconnais volontiers un bon point avec Python par rapport à Perl: une vraie spécification, qui a permis, outre la version C, d'avoir une implémentation pour les machines virtuelles Java et .NET. En Perl on en est encore loin.

C'est un fait que la majorité des langages de script se soucient peu de compatibilité ascendante. Pourtant ça devrait être même plus important encore que pour des langages compilés, parce qu'on peut se retrouver à devoir exécuter des anciens scripts. Et concernant Python c'est justement mon cas : actuellement j'ai un Python 2.7 dans mon environnement qui sert juste à exécuter certains programmes dont je dépends. Demain il faudra peut-être en plus un environnement Python 3, 4, 5... juste pour exécuter les scripts qui n'ont pas été migrés (ou qui n'ont pas pu, parce qu'ils dépendent d'une librairie qui ne l'a pas été)?
J'ai eu le même problème avec des programmes Ruby entre la 1.8 et la 1.9 (tiens, ils avaient pourtant juste changé le numéro de mineure?), moins souvent avec PhP.
Bizarrement, les langages semi-compilés comme C# ou Java se soucient bien plus de la rétro-compatibilité, quitte à trainer derrière eux des structures que plus personne n'utilise, alors que là, la rétro-compatibilité entre binaires (ou entre VM si vous préférez) serait amplement suffisante et même plus facile à assurer. Cherchez l'erreur...

Mais puisqu'il est question ici d'une période de transition, il est temps pour moi de faire la comparaison avec Perl dont je parlais au début.
Entre Perl 4 et 5, il y a eu plein de nouveautés introduisant des incompatibilités. Mais comme il s'était écoulé peu de temps entre ces versions, tout le monde a migré ses programmes et même avant l'an 2000 on ne parlait quasiment déjà plus de Perl 4.
Puis est arrivée la rumeur Perl 6, une vraie spécification (enfin!) et les premières tentatives d'implémentation... et une période de transition qui dure depuis maintenant 15 ans! Larry Wall a prévu de sortir la première version stable de Rakudo cette année mais pour ce qui est de Perl 5, on en est maintenant à la 5.20 (tiens, je parlais encore il y a quelques minutes de numéros à 2 chiffres...) qui est truffée de rétro-portages de nouveautés de Perl 6. Et on trouve même un package perl6-v qui permet d'interpréter du Perl 6 en Perl 5! Sans même parler des différences entre les deux langages (typage fort, modèle objet complètement différent...) je crois qu'on est pas prêts de voir une migration en masse vers cette nouvelle version.

Alors, conclusion?
Pour moi la meilleure solution, quel que soit le langage, serait de se donner un cahier des charges bien moins ambitieux d'une version à la suivante. Au lieu de re-spécifier un nouveau langage qui ne partage guère que le nom avec la version précédente (au risque qu'un même programme fonctionne dans les deux versions mais avec un comportement différent...) il vaudrait mieux spécifier une dizaine de nouveautés, on prend le temps de se mettre d'accord sur la spec et ensuite on implémente, quitte à déjà commencer à spécifier la version suivante. Plus les versions sont rapprochées, plus la transition est facile.
19/02/2015, 15h09
VinsS

Il existe une convention de versionnement communément admise, et c'est le cas dans l'univers Python, qui nous dit que le numéro majeur de version est incrémenté lorsqu' apparaissent des changements rétro-incompatibles. Je m'étonne donc du désappointement de développeurs découvrant qu'il leur faudra réécrire du code lors du passage à une nouvelle version majeure.

On est censés savoir ce qu'implique une rétro-incompatibilité et, en Python du moins, nous sommes adultes consentants.

Le cas de Python n'est pourtant pas si contraignant que cela. Que doivent penser les développeurs C++ utilisant le framework Qt ? Les changements introduit avec la version 5 nécessite une réécriture beaucoup plus coûteuse en temps et je n'ai pourtant pas eu l'impression que ces changements aient fait autant de vagues que le passage à Python 3.

Et puis il y a la question des librairies tierces. Ces librairies qui, après six ans, n'ont toujours pas été portées sous Python 3 doivent simplement être considérées comme abandonnées. C'est soit l'occasion d'aller voir ce qui existe ailleurs, soit de découvrir qu'il n'est pas si compliqué que cela de forker un code et de publier sa version compatible Py3. Je n'y vois que des aspects enrichissants.

Python 3 n'est nullement une erreur, c'est une étape logique dans une progression régulière. Progression souhaitée par les développeurs. Le Tout-à-l'Unicode enfin !

Et une étape transitoire ?

C'est quoi une étape transitoire ?

Ça ?

Citation:

En 2018 tous les pays de la zone Euro devront adopter la circulation automobile à gauche.
Il est toutefois prévu une période d'adaptation, nous commencerons par les camions.

Sans rire, des gens ont réellement pensé possible une version à mi-chemin 2-3 ?

Notons tout de même qu'à l'intérieur de la version 2 existe un module de transition: __future__.

Je pense que Python à encore de beaux jours devant lui. D'ailleurs, tant qu'on est dans un forum bistrot, personne n'a de nouvelles de Python 4 ?

Vincent
19/02/2015, 15h23
noirbizarre
Les étapes de transitions ont existées, bien plus que dans n'importe quel autre langage.

Le problème n'est pas Python 3 en lui même: les changements sont vraiment mineurs et étaient plus attendus qu'autre chose.
La cohérence introduite et le nettoyage étaient nécessaires.
Le problème, alors que l'annonce de Python 3 a bientôt 10 ans, c'est le fait qu'il y ai encore des librairies structurantes qui ne soient pas compatibles avec Python 3.
Cette situation existe parce qu'on la permet:
- on maintient encore un version 2.7
- on donne raison à ceux qui maintiennent des serveurs utilisant Python 2.5 (non mais allo quoi!)
Si on arrête le support de Python 2.7, vous verrez que rapidement l'adoption de Python 3 ne sera plus un problème.

Il suffit de regarder ici pour voir les points de blocage: https://python3wos.appspot.com/
Les projets en rouge dans cette liste sont exactement les raisons qui font la non-adoption de Python 3.

A chaque fois que je démarre un projet, il faut vérifier que les libs dont on a besoin sont compatibles Python 3.
Dernièrement je revois un peu mes choix: j'essaie autant que possible de me passer de ces librairies qui ne sont pas compatibles Python 3, quite, lorsque c'est possible, à la recoder.
Malheureusement ce n'est pas toujours possible, ce qui impose souvent l'usage de Python 2. C'est malheureux.
Certains projets ont même déjà les pull-requests pour un support Python 3, c'est juste le leaddev qui bloque, n'en voyant pas l’intérêt.

Au final, on est dans la même situation que le support IE6 qui a duré bien trop longtemps.
Il a fallu que les sites les plus importants (gmail, facebook...) annoncent qu'ils ne supportent plus IE6 pour que tout le monde se dise "si eux le font je peux le faire".
L'adoption de Python 3 ne se fera pas tant qu'il y aura un support de Python 2 puisqu'en substance, le message envoyé est: "ce n'est pas grave si vous ne passez pas à Python 3, on vous maintient Python 2 pour que vous soyez encore content 10 ans après".

Pour avoir fait beaucoup de portages vers Python 3, il n'y a rien d'insurmontable, c'est vraiment très simple à faire, surtout avec des couches d'abstraction comme Six.
Qu'il y ai encore des libs majeures qui ne soient pas passées à Python 3 est le problème fondamental cela bloque le démarrage de nouveaux projets en Python 3.

De voir aujourd'hui des outils innovants (que j'utilise :() qui sortent sans supporter Python 3 me scandalise (fig, ansible...) !
Lorsqu'on leur pose la question, ils répondent, au choix!
- on préfère utiliser Python 2 parce que il faut supporter des serveurs ancestraux,
- je dépend de telle lib qui n'est pas compatible
Bref, tout ça pour dire que si tout le monde attend tout le monde, il ne se passe rien !
Donc, dès que vous en avez la possibilité, utilisez Python 3 !!!
Je pense d'ailleurs que les nouvelles fonctionnalités introduites dans les dernières versions (ex. AsyncIO) attireront des plus en plus de développeurs.

PS: publier une analyse des résultats avec 26 participants n'est pas vraiment pertinent puisque 54% des développeurs (cf. punchline de l'article) représente 14 développeurs et je ne pense pas en l’occurrence que cela représente un échantillon représentatif des développeurs Python.
19/02/2015, 15h38
yahiko

J'aime beaucoup la mentalité "yaka fokon" de certains.

Ben voyons, c'est bien connu qu'une boite aime payer ses devs à développer des choses qui n'apportent pas de nouvelles fonctionnalités comme un portage de toute une base de code d'une version d'un langage à une autre parce que des gens à l'autre bout du globe refusent la retro-compatibilité et le support...
19/02/2015, 16h25
noirbizarre

Citation:

Envoyé par VinsS

Il existe une convention de versionnement communément admise, et c'est le cas dans l'univers Python, qui nous dit que le numéro majeur de version est incrémenté lorsqu' apparaissent des changements rétro-incompatibles. Je m'étonne donc du désappointement de développeurs découvrant qu'il leur faudra réécrire du code lors du passage à une nouvelle version majeure.

On est censés savoir ce qu'implique une rétro-incompatibilité et, en Python du moins, nous sommes adultes consentants.

Le cas de Python n'est pourtant pas si contraignant que cela. Que doivent penser les développeurs C++ utilisant le framework Qt ? Les changements introduit avec la version 5 nécessite une réécriture beaucoup plus coûteuse en temps et je n'ai pourtant pas eu l'impression que ces changements aient fait autant de vagues que le passage à Python 3.

+1!! La rétrocompatibilité est plutôt l'exception que la règle.
Python a géré la transition vers Python 3 depuis la version 2.5 de Python. Je ne vois pas ce qu'il faut de plus comme étape transitoire.

Citation:

Envoyé par yahiko

Non, vraiment, cette façon de faire table rase à chaque version majeure fait que Python ne sera jamais pris sérieusement dans le monde professionnel.

8O 8O N'importe quoi !!!
Ruby ne gère pas la rétrocompatibilité et est massivement utilisé.
PHP, Perl... ne gèrent pas la rétrocompatibilité et sont utilisés.
C, C++... il n'y a pas de rétrocompatibilité et c'est utilisé en entreprise.
.Net ne gère pas une rétrocompatibilité totale, mais c'est utilisé.
Il n'y a bien que Java qui essaie de faire croire qu'il y a une vrai rétrocompatibilité, mais en pratique ce n'est pas vraiment le cas puisque pour une même version, sur des JVMs différentes il y a déjà des incompatibilités.

Python, pas utilisé dans le monde professionnel ?!?!?
Ça me fait bien rire: toutes les boites qui travaillent de la donnée, du spatial, du matriciel, qui font du machine learning, ... utilisent Python.
Ils choisissent Python, non pas pour la rétrocompatibilité, mais pour l’écosystème et l'outillage qu'il tire, pour la facilité d'apprentissage puis de maintenance.
Il ne doit y avoir que les banques qui prennent en compte cet argument, parce que Oracle leur a dit "venez chez nous, vous payerez un bras pour du support et une illusion de rétrocompatibilité" !
Le problème sur les chiffres de l'informatique, c'est que les banques représentent la plus grosse partie du marché, que les recruteur et les SSII veulent leur part du gâteau et qu'au lieu de leur dire "vous savez, depuis les années 2000, on sait faire mieux", elle disent "oui oui, tout ce que vous voudrez" !
Les méthodes de comptages sont souvent très discutables (du nombre de recherches sur Google à un sondage sur un panel d'entreprises non représentatives).

Aucune SSII ne m'a jamais proposé de mission sur des stacks à base de Python: "Il n'y a pas de marché", "C'est un langage de script"... Bref, j'en ai entendu de toutes les couleurs.
Maintenant je me débrouille sans eux, et, à ma grande surprise (je suis naïf, je sais), toutes les boites sont en galère parce qu'elles cherchent des devs Python et qu'il en manque beaucoup!!!
Même les SSII qui m'avaient dit "Python=No Go" m'ont recontacté pour ça, toutes sans exception!
Bref, Python en entreprise, ça existe et il y en a de plus en plus.
19/02/2015, 16h35
yahiko

Ruby, je ne connais pas assez, mais j'en ai rarement croisé des applications pro dans ce langage.
Pour PHP, .Net ça se passe côté serveur. Pas besoin de migrer si on n'en a pas envie ce que beaucoup de boites ne se gênent pas de faire.
C, C++... Comment dire... C'est du langage compilé donc pas besoin de déployer/packager un interpréteur par client. C'est normalisé depuis des années (décennies). C'est inquiétant si tu n'es pas au courant. Et les évolutions sont mûrement réfléchies et débattues avec pour souci de s'intégrer à l'existant (un certain respect des utilisateurs donc)

Donc oui, la non rétro-compatibilité pour un langage interprété côté client comme Python est une plaie.
Les fans du langage auront beau répéter le contraire et mettre des pouces rouges, mais ça ne changera pas la réalité. ;)
19/02/2015, 17h45
air-dex

Je suis pro-Python 3 car c'est l'avenir de Python. J'ai appris le Python avec Python 3 pour cette raison. Persister sur Python 2 c'est comme persister sur GTK 2 et Qt 4 à l'heure de GTK 3 et Qt 5. Cela n'a aucun sens.

Citation:

Envoyé par yahiko

Au pire, il y a toujours la possibilité de créer un nouveau langage sans pour autant pousser une communauté à abandonner un langage en place et qui pourrait évoluer autrement.

Dans les faits : "on n'aime pas le passage de Python 2 à Python 3 donc on forke Python 2 dans un nouveau langage nommé [mettre un nom de serpent ici, pourquoi pas "Cobra"] qui sera Python 2 avec les évolutions de Python 3 et une rétrocompatibilité avec Python 2" + tout le toutim qui va avec de tels forks (une news sur les sites d'IT à l'annonce du fork puis plus rien, dispersion des devs et à terme mort du fork dans l'indifférence générale).

Honnêtement ? Non merci pour ce "yet another fork". :nono: On donne déjà assez comme ça.
19/02/2015, 17h57
mangobango

Hum, il y a beaucoup de mélange dans les derniers posts...

Pour C++ le langage OK, en soit il est rétrocompatible, pas de souci... du moment que t'as toujours utilisé un compilateur 100% conforme, des librairies 100% conformes et que ton code est 100% conforme sur un seul OS. Il n'y a pas eu de rupture dans le langage (la syntaxe et la std) mais l'environnement dans lequel s'exécute le code (assimilable à un interpréteur bas-niveau) lui a beaucoup bougé! En clair, le C++ n'est pas (toujours) rétro-compatible parce que l'environnement d'exécution ne l'est pas (toujours), comme pour un interpréteur*. Pour tout programme, son environnement d'exécution est une cible mouvante.

Et en quoi Python est-il un langage "client" ? C'est quoi un langage "client"? :weird:

Daniel

*Par ailleurs, il est plus facile et moins couteux d'installer un interpréteur que de changer de machine.
20/02/2015, 09h16
tyrtamos

Bonjour,

Juste un petit complément: le Python proposé par les hébergeurs web.

En plus d'un site "normal" (cms apache-php-mysql), j'ai une petite application en Python 2.6 CGI (une calculatrice scientifique en ligne). Comme je suis passé en Python 3, j'aimerais que mon hébergeur passe aussi à Python 3 pour ne pas à avoir le même code géré chez moi dans les 2 versions.

J'ai posé la question à mon hébergeur (pourtant sérieux, suisse, cher...) pour avoir Python 3.2 au lieu de 6.6, et sa réponse c'est: prenez un serveur autonome et vous pourrez y mettre ce que vous voulez. Coût de l'opération: 4 fois ce que je paye actuellement. Ben voyons...

J'ai alors fait un petit tour rapide: c'est effarant! La quasi totalité des hébergeurs qui proposent Python en sont à Python 2. Les meilleurs à Python 2.6 (sorti en 2008), mais plusieurs proposent Python 2.2 sorti en 2001, donc il y a 14 ans, et certains s'en vantent...

Plusieurs hébergeurs proposent Python mais ne disent pas quelle version. Il faut donc passer commande pour le savoir? N'importe quoi.

Bref: actuellement, mes codes qui seront développés en même temps en Python 3 et pour le web, seront écrits en multi-version. Pas chouette... :(

Ce serait bien que les éditeurs de Python travaillent un peu sur tous les freins qui empêchent le passage à Python 3, parce que si ça continue, dans 20 ans on parlera encore de Python 2...
23/02/2015, 08h08
redbullch

@tyrtamos

Pour l’hébergement, il y a OpenShift qui propose python 3.3 (en plus des versions antérieures).
23/02/2015, 08h29
tyrtamos

Bonjour,

Citation:

Envoyé par redbullch

Pour l’hébergement, il y a OpenShift qui propose python 3.3 (en plus des versions antérieures).

Merci redbullch, je vais regarder si je peux transporter ma calculatrice là bas.

Puisque je vois que tu es suisse, mon hébergeur actuel est: infomaniak à Genève (https://www.infomaniak.fr/fr). J'y suis depuis plusieurs années, et à part pour la version de Python, il a une excellente qualité de service.