Personnellement je suis encore dessus uniquement car je développe sur Google AppEngine qui est bloqué en version 2 pour l'environnement standard ... Parfois on a juste pas trop le choix.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Personnellement je suis encore dessus uniquement car je développe sur Google AppEngine qui est bloqué en version 2 pour l'environnement standard ... Parfois on a juste pas trop le choix.
Ce que devrait permettre python3 (et Guido) c'est de pouvoir utiliser les librairies de python2 si elles n'ont pas été réécrites.
De cette manière les anciennes librairies seraient toujours présentes, ne cassant pas la rétro-compatibilité.
Maintenant je peux comprendre qu'il veuille que le code évolue et uniformiser la syntaxe (depuis le début) avec l'indentation...
Il pourrait rendre python plus "pythonlish" tel que perl était perlish.
Mouais. Je viens de commencer un nouveau projet et j'ai tenté de le faire en P3. J'avais tout préparé. Qt5 + PyQt, l'utf8, etc. Et patatrac, j'ai besoin de qgis et elle n'est dispo qu'en P2. Donc ben je suis reparti en P2 (mais j'ai activé tous les from __future__ en prévision du futur justementEnvoyé par VinsS
).
Donc qgis, librairie utilisée dans le SIG "QGis". Doit-elle être considérée comme abandonnée ???
Le version 3.0 sortie il y a 3 semaines n'est pas justement en python 3 ?Mouais. Je viens de commencer un nouveau projet et j'ai tenté de le faire en P3. J'avais tout préparé. Qt5 + PyQt, l'utf8, etc. Et patatrac, j'ai besoin de qgis et elle n'est dispo qu'en P2. Donc ben je suis reparti en P2 (mais j'ai activé tous les from __future__ en prévision du futur justement
Donc qgis, librairie utilisée dans le SIG "QGis". Doit-elle être considérée comme abandonnée ???
Je ne dis pas qu'ils sont abandonnés mais doivent être considérés comme tel.
Je ne connais QGis que de nom donc je suis allé voir leur doc [0] et la première chose qui m'a sauté aux yeux c'est PyQt4
Doublement abandonné !
Mais bon, il semble que Sarénya a un meilleur Google que moi ...
[0] https://docs.qgis.org/2.14/fr/docs/p...ook/intro.html
La version 3.0 était déjà en version 3Le version 3.0 sortie il y a 3 semaines n'est pas justement en python 3 ?
La conversion bytes str est un faux problème
Le vrai problème se situe dans les libs tierces qui ne sont pas mises à niveau suffisamment rapidement.
Exemple wxPython dont le portage phoenix n'est toujours pas abouti. Pour passer à la branche 3 j'ai décidé de me passer de wxPython et de m'orienter sur pyqt5 et je ne regrette rien.
Bonjour,
J'ai bien peur que la poursuite de la maintenance de Python 2 jusqu'à 2020 donne un mauvais signal à tous ceux qui se diront alors: on peut donc attendre 2020 avant de faire quoi que ce soit... En fait, il était prévu à l'origine 5 ans de conversions à partir de décembre 2008, et ça aurait donc dû finir en décembre 2013. A mon avis, s'il y a eu une erreur, c'est bien de maintenir Python 2 après 2013. On peut craindre, malheureusement, qu'en 2020, il soit encore décidé de le maintenir encore jusqu'en 2030, et ce n'est certainement pas parce que Python 2 est meilleur! En ce qui me concerne, quand je vois les progrès de Python 3 par rapport à Python 2, et en particulier (mais pas seulement!) la gestion des Unicodes, je ne reviendrai pas en arrière! Peut-être même aurais-je changé de langage si Python 3 n'avait pas existé.
A part certains modules qui ont été cités et qui restent sous Python 2, je sais que deux organismes sont aussi responsables d'une aussi longue durée de Python 2: les hébergeurs et les éditeurs de Linux. Il y a bien sûr une relation entre les deux puisque la plupart des serveurs sont sous Linux. Pour les hébergeurs qui ont Python CGI dans leurs offres, c'est même pire puisqu'on trouve encore Python 2.6, voire Python 2.5. Ça commence à évoluer, mais c'est long... La dernière fois que j'ai demandé à mon hébergeur de passer sous Python 3, il m'a recommandé de me mettre plutôt sur un serveur dédié, ce qui m'aurait fait payer par mois ce que je payais pas an! Ce qui fait que certains de mes programmes sont maintenus sous Python 3 ET sous Python 2, ce qui est une complexité inutile. Mais avec le temps qui passe, peut-être vais-je choisir mon hébergeur en fonction de sa version de Python.
Mais il ne faut jamais oublier que la plupart des modules que nous utilisons sont gratuits, ce qui est un grand avantage pour nous (j'ai abandonné Delphi en 2007 à cause de son prix). En contrepartie, ils dépendent du bon vouloir de bénévoles (y compris si c'est du "bénévolat d'entreprises"). Il suffit que le principal pilote se détourne de son produit ou change de métier (ou disparaisse?), pour que le module ne soit plus maintenu. J'espère que Guido van Rossum, qui nous a donné un chouette produit, a bien prévu la suite...
un "mal" nécessaire
Je développe exclusivement sous python3, dans les 2 dernières versions (3.5 et 3.6 actuelement)
Cela me gonfle de voir encore sur le web des gens coder en python 2.7
Cela me gonfle de voir en 2018 des scripts python 2.7 dans les distro linux
Cela me gonfle encore plus de voir certaines distribution linux mettre python 2.7 par défaut au lieu de python3.
Je pense qu'il faut faire du forcing et ce débarrasser complétement de cette antiquité. Il faut forcer les dev a adopter python3.
Sans maj de sécurité déja les distribution linux devrons l'enlever par défaut ce qui forcera ces feignasses a enfin mettre à jours leurs scripts.
Python3 n'a que des avantages par rapport à python 2.7
J'ai fait du Python 2.7 il y a trop longtemps.
Un fork indépendant pour le 2.7 sous un autre nom règlerait le problème. Et 3 pourrait enfin s'épanouir, ou disparaître. Selon son destin.
Ouais, bref tout te gonfle quoi !!! A force de trop te gonfler, t'as pas peur de t'envoler ???
Allez, yfo, yaka, ynoufon...
Ok, en avant les lieux communs et les affirmations gratuites...
Je pense qu'avant que cela te gonfle, tu devrais penser en terme de développeurs de ces applications. T'es-tu rien qu'un instant posé la question du pourquoi ces scripts ne sont pas modifiés au niveau de la version python? Malheureusement on ne peut pas toujours faire ce que l'on veut, surtout quand on a certains scripts qui ont de multiples dépendances.
bah en 10ans si on peut y faire quelque chose.
Je développe pleins de programmes en python et j'ai réussie à faire la migration et a résoudre mes problèmes de dépendances. Il a fallu recoder certain script et j'en suis pas mort !
Quand les distrib on utilisé systemd pareil y'a fallu que je recode beaucoup de mes scripts et de mes installeurs rpm qui était incompatible, je l'ai fait ! pendant d'autre on chouiner au changement sont partis dans des solutions pas crédible style devuan
Ou le passage à firefox 57...
Si y'a un fork de python2.7, j'espere que personne ne l'utilisera cela ne peut que nuire au langage.
En informatique faut savoir évoluer... sinon tu reste à coder en C seul langage que je connaisse qui évolue très peu dans le temps
je parle en connaissance de cause !
Python3 est plus performant, est plus cohérent, meilleur gestion des exceptions...Ok, en avant les lieux communs et les affirmations gratuites...
Python2.7 n'a aucun avantage face à python3
si tu n'est pas content bah vas y donne tes arguments qu'on rigole au lieu d'envoyer des petite bassesse
N'inverse pas les rôles. Ce n'est pas moi qui fait des affirmations gratuites et non étayées.
Moi, je me contente de regarder et de réfléchir en me disant que si les gens continuent à forcer P2 (ici ils parlent de continuer jusqu'en 2027) c'est qu'il doit y avoir une raison un peu plus sérieuse que faire enfler RyzenOC; et que si tyrtamos prend de son temps pour faire évoluer ses codes en parallèle sous P2 et P3 ce n'est certainement pas parce qu'il n'a rien d'autre à faire.
ici l'intervenant dit que son algo sous P3 tourne 30 fois plus lentement que sous P2. Alors vrai/pas vrai ? J'en sais rien mais c'est quand-même un détail de plus à prendre en considération (pour celui qui a un esprit un minimum ouvert).
Je ne sais pas ce que tu codes en Python mais je sais que celui qui veut porter ce type d'instruction sorted(iterable, cmp=fct) de P2 vers P3 aura un peu plus de travail que de remplacer "xrange()" par "range()". Alors certes functools contient le fameux "cmp_to_key" qui, déjà, évite à tous un gros travail... mais l'instruction deviendra sorted(iterable, key=cmp_to_key(fct)) et déjà ça c'est un travail qui ne se fait pas en dilettante. Et en plus oui, ça fonctionne... mais tu remarqueras que cela provoque une indirection (ou un appel) supplémentaire et bon, sans être spécialement matheux, on sent intuitivement qu'un truc qui fait une opération en plus pour faire la même chose qu'un autre truc ben fatalement il doit le faire en un peu plus de temps.
Et c'était un exemple que je connais mais il doit sûrement y en avoir d'autres que je ne connais pas. Tu penses aussi à tous ceux qui utilisent le slash comme division euclidienne ???
Je ne dis pas que P3 n'a pas de bons trucs, et que je n'aimerais pas y passer, mais peut-être que certains ont plus de soucis pour y venir que de passer de bêtes scripts shells de systemV vers systemd. Et (accessoirement je vois que tu utilises rpm alors que moi, qui suis sous Debian, je travaille avec apt mais tu vois, je ne viens pas te dire "ouais ça me gonfle ceux qui utilisent des trucs aussi has been que les rpm").
Encore une affirmation gratuite. Donc LibreOffice n'a pu que nuire à OpenOffice, qui n'a pu que nuire à StarOffice. Waterfox (et/ou Iceweasel) n'ont pu que nuire à Firefox et VeraCrypt ne peut que nuire à TrueCrypt (en plus pour lui c'est vrai qu'il est mort... mais ce n'est pas la faute de son fork). Et PySide ne peut que nuire à PyQt.
S'il y a un fork, ça fera ce qu'ont fait tous les fork. Peut-être il sera meilleur, peut-être il sera moins bon, peut-être il sera du même niveau. Peut-être que les gens l'aimeront, peut-être qu'ils ne l'aimeront pas. Mais comment pourrait-il nuire à Python sans que ce soit d'abord de la faute de Python lui-même ?
Amusant. Deux phrases en exacte opposition l'une par rapport à l'autre...
Si tu souhaite contrer mes propos bah si il faut bien argumenter au lieu de me répondre avec un ton hautain sans rien apporter à ola conversation (ce que tu as fait dans ce message, ce qui est bien)
ton exemple est tres mauvais car déja il se base sur de la chance et de plus l'auteur ne semble pas bien maitrisé ce langage et comme il le dit lui meme :
Regarde de vrai benchmark sur le net parce que je suis désolé mais ton lien ne prouve rien du tous ! l'auteur ne donne meme pas de chiffre....J'ai bien conscience du caractère aléatoire de l'algorithme, ce qui peut expliquer certaines variations dans le temps d'exécution.
Je n'ai pas fait de mesures exactes, c'est juste un constat général du fait que cette partie du code étant exécuté quasi-instantanément en 2.7, met maintenant plusieurs minutes à s'exécuter en python 3.5. J'ai retrouvé les mêmes ordres de grandeur pour une dizaine d'essais dans chaque version, je pensais donc qu'il pouvait y avoir une explication technologique, plutôt que de la simple malchance.
Je fais du HPC avec python donc j'utilise principalement numpy/scipy. Donc la performance est ma priorité !
Les exemples que tu décris sont des consertion de syntaxe pour rendre le langage plus cohérent !
c'est le meilleur exemple justement d'incohérence de python2.7 ! il fallait le virer
Ton exemple est pas bon. rpm/apt c'est juste un format... Sa me gonfle effectivement que y'ait pas un standard dans linux, j'aimerais bien que y'ait plus de rpm,deb,apk (alpine linux pas android),pup... juste 1 seul format de package.
Y'a ubuntu qu'a lancé snap mais pas de bol personne ne suit...
Aujourd'hui systemd est géniale, car il permis de grandement unifier les distributions linux !
mais Debian ou redHat ne sont pas has been, moi j'utilise des rpm parceque en entreprise on veut un support donc redhat donc rpm.
OpenOffice nuit à LibreOffice.
LibreOffice a été crée avec quais tous les dev de openoffice suite à l’acquisition d'oracle. Cela n'a donc rien à voir.
Iceweasel aussi à nuit à firefox suite à un contentieux avec mozilla et debizn !
Ce sont des fork qui n'apporte rien car le but ce n'est pas de crée quelque de chose de nouveau c'est juste pour dire je suis pas cotnent. Mais Debian n'a strictement rien foutue avec iceweasel à part renommer firefox ar iceweasel ! Mais aujourd'hui ces messieurs ont grandi et compris leurs connerie et ont abandonné iceweasel et installe firefox par défaut.
Non pas vraiment.
Python est grandement développé grace à de grosses entreprises (intel, MS...), python3 est ce qu'il est grace à eux.
Un fork de python 2.7 serait fait par 2-3 barbu réfractaire au changement et ils n'apporterais rien au langage si ce n'est de faire vivre un légume
Bonjour,
Il y a dans le wiki du site Python officiel une page très intéressante sur le sujet: Python 2 ou 3?
=> https://wiki.python.org/moin/Python2orPython3
Il ressort bien que "on utilise Python 2 quand on ne peut pas faire autrement", mais je trouve que cette page est un peu trop "arrangeante" pour Python 2. Autrement dit, pour moi, elle ne pousse pas assez fort vers Python 3, et le résultat est peut-être la situation actuelle. Par exemple, le fait que des améliorations de Python 3 aient été "rétro-portées" vers Python 2 ne va pas dans la bonne direction. De même pour l'existence d'un code "3to2"...
Je me rappelle bien quand j'ai dû faire la conversion Python 2=>3 de plusieurs Go de codes. J'ai utilisé "2to3" dans un programme créé pour automatiser la conversion, mais ça n'en résout que 90%. Après il faut faire "à la main" pour que le code fonctionne, puis utiliser (absolument!) un analyseur de code comme "pylint" pour compléter les vérifications-corrections, puis enfin, améliorer le code pour bénéficier des améliorations de Python 3. Et il a fallu que je fasse pareil pour passer de PyQt4 à PyQt5. J'ai d'ailleurs créé pour ça un programme de recherche-remplacement multi-fichiers qui m'a bien servi. Tout cela m'a demandé 2 ans, mais je ne l'ai pas regretté par la suite!
Il est évident que la grosse amélioration de Python 3 est le traitement des chaines grâce à l’Unicode. Dans ce cadre, il y a des améliorations dans les modules qui ne sont pas spectaculaires mais rendent la vie beaucoup plus facile. Par exemple, le module csv qui permet de lire et écrire des fichiers csv pour échanger des données avec les tableurs et les bases de données. L'ouverture de ces fichiers étaient binaires ('rb' et 'wb') avec Python 2 et texte ('r' et 'w') avec Python 3. Cela parait anodin, mais c'est important quand on veut gérer comme moi des données multilingues (avec des accents qui ne sont pas seulement français). J'avais fait une fonction spéciale complexe de décodage/encodage en passant par l’intermédiaire d'un fichier mémoire avec Python 2, que j'ai mis à la poubelle avec Python 3! J'ai d'autres exemples en tête qui vont dans le sens d'une plus grande facilité de traitement des textes internationaux: grâce à l'Unicode, il est facile de retirer des accents de majuscules et minuscules pour faire certaines recherches, sans avoir recours à des listes prédéfinies de caractères. Etc...
Par ailleurs, il existe bien des modules qui "tardent" à évoluer vers Python 3, mais il existe aussi le contraire: des modules qui continuent d'évoluer sous Python 3, mais qui ne sont plus maintenus sous Python 2. Par exemple la bibliothèque graphique PyQt que j'utilise beaucoup. Et il y a ainsi des améliorations très intéressantes de PyQt5/python3 dont on se prive avec PyQt4/Python2 (navigateur web, modules multimedia, ...).
En fait, la principale raison pour passer de Python 2 à Python 3 est que Python 3 continuera à évoluer, et ses modules aussi, alors que ce ne sera pas le cas de Python 2.
Le problème c'est que tout les développeurs ne souhaitent pas soutenir leurs modules python. Le seul reproche que l'on puisse faire, c'est que certains enseignants se cantonnent encore à python 2.x pour apprendre à leurs élèves l'algorithmie. Là il n'y a aucune raison... Effectivement !
Je suis d'accord sur le fait qu'il faudrait upgrade les scripts vers la version 3.x, cependant si ce n'est pas fait, il faut en connaître la raison... et c'est certainement une bonne raison, sinon ça serait fait depuis bien longtemps, surtout quand on connaît l'âge de python 3.x
Ben oui mais c'est toi qui a commencé avec tes "ça me gonfle..." comme si t'étais le centre mondial des utilisateurs Python...
Il n'était pas là pour prouver, mais pour illustrer. De plus tyrtamos a aussi écrit.J'avais remarqué ça aussi, mais je ne sais pas pourquoi
Ben c'est comme pour tout. On en trouve dans tous les sens.
https://twitter.com/VictorStinner/st...05065708376069
https://twitter.com/VictorStinner/st...89596683210760
https://www.quora.com/How-fast-is-Py...ompared-to-2-7
Alors certes certains de ces liens sont vieux (2013) et on en trouve où aujourd'hui P3 apparait comme plus rapide
https://dev.europython.eu/conference...r-than-python2
https://igordavydenko.com/talks/by-pycon-2017/#slide-16 (il faut utiliser les flèches pour passer d'une page à l'autre)
Mais c'est aujourd'hui que ça arrive, alors que P3 a 10 ans. En plus ils comparent même P3.5 à P3.6, c'est quand-même un signe ça !!! Signe de "ouais c'est vrai, P3.x (x <= 5) était pas terrible on s'en rend bien compte et la SNCF s'excuse pour le retard dû au conducteur qui ne s'est pas réveillé et qui a foutu 300 voyageurs en rade pour leur WE mais bon, maintenant faites-nous confiance, on le fera plus promis". Et tu veux reprocher aux gens de ne pas faire confiance à ces promesses, ou même plus simplement de ne pas y avoir fait confiance il y a 10 ans, c'est à dire 10 ans avant que ces promesses ne soient faites aujourd'hui ???
Peut-être mais ça ne se règlera pas avec un simple "cherche et remplace".
Euh c'est tout de même comme ça que ça fonctionne en C, en php et dans (à mon avis) tous les autres langages typés. En fait, le double slash ben je ne le vois que dans Python3.
Mais de toute façon quel que soit le motif du changement de syntaxe ça ne change pas le final. Les dev ; qui ont utilisé P2 selons les promesses de P2 de l'époque et qu'on ne peut donc pas condamner et donc qui font parfois des divisions euclidiennes ou qui font parfois des divisions exactes ; ne porteront pas leurs librairies avec un :g/\//s//\/\//g !!! Moi même je viens de faire le compte. J'ai dans mes différents projets 313460 lignes de code (compte brut, via find name "*.py" -exec wc {} + donc en incluant les commentaires et tout mais bon, ça illustre). Tu crois que je vais les passer à 2to3 "en confiance" ??? Et ce ne sont que de "petits" exemples par rapport à toutes les différences qui existent et qui doivent être prises en compte ; multipliées par la quantité de code à porter !!!
C'est plutôt pour dire "j'aimerais qu'il y ait ça et ça ne vient pas donc je le fais moi-même". Parce que moi j'ai trouvé que waterfox (qui était en fait du firefox 64bits) m'a apporté pas mal (le 64 bits justement). Tu me rappelles combien de temps on a attendu un firefox 64 bits ??? Ben tellement longtemps que quand il est sorti, je me suis dit "bah, waterfox t'a bien rendu service, alors sois sympa et ne le jette pas sous prétexte que le retardataire vient enfin d'arriver". Et quand TrueCrypt a disparu et que je n'étais pas convaincu par leurs arguments ("oui, on arrête TrueCrypt parce qu'on fait confiance à BitLocker développé par Microsoft") ben j'ai été super heureux 1) d'avoir conservé mes différentes versions (je conserve toujours 2 ou 3 historiques de versions des logiciels que j'utilise) et 2) de voir arriver VeraCrypt (le fork qui n'apporte rien car son but n'est pas de créer quelque chose de nouveau).
[HS]Et quand j'entends en plus le vice-amiral Coustillière, patron de la cyberdéfense, qui dit dans un reportage "ouais, on sait bien que Microsoft a laissé des backdoors mais bon, ça ne nous dérange pas vu que les américains sont nos potes"
Euh c'est surtout une histoire de droit à l'image. Debian ne veut (voulait) que du 100% libre et dans firefox, l'image du renard roux est (était) propriétaire.
Ou peut-être parce que le souci de l'image n'est plus un souci...
Quand y'auras plus de maj de sécurité les distributions linux devrons l'abandonner ! elles devrons s'adapter, peut etre que certaines fonctionnalités serons abandonné.
C'est comme pour WindowsXP, quand MS a arrêter le support les entreprises l'ont enfin abandonné pour de bon... pourtant y'avaient de "bonne raison" de rester sur windowsXP...
Les enseignants enseigne python2.7 peut etre parce que quand tu tape python sous certaines distribution linux très populaire tu as python2.7 par défaut ! il faut taper python3 pour avoir python 3
Y'a surement des bonnes raisons de rester sous python2.7 mais à un moment donner la PSF doit prendre ces responsabilités et arrêter dépenser des ressources dans le maintient de cette version et se concentrer exclusivement sur l'avenir : un python4.0 orienté multicœurs.
Python, c'est bien pour prototyper ou si les algos se résument à des appels à numpy/scipy (dont une grosse partie du code est en C/C++/Fortran). Mais quand les algos deviennent plus complexes, la lenteur de python est souvent rédhibitoire. Et ça ne risque pas de changer, à cause de ses choix de conception (typage dynamique, pas de compilation JIT efficace, GIL...). Au boulot, on utilise de plus en plus Julia et ça nous change la vie.
En quoi est-ce un problème qu'il y ait plusieurs formats de package ? Les packages sont des éléments internes des distribs, qui doivent être faits par les mainteneurs, qui connaissent toutes les particularités de leur distrib pour faire ça correctement. Si tu veux vraiment faire tes propres paquets génériques (et donc peu optimisés), tu peux utiliser snap ou flatpack. Et si tu veux des packages adaptés au HPC, il faut juste oublier tout ça et aller voir du côté de easybuild, spack, conda, guix... et là c'est carrément le bordel.
Répondre avec citation
Partager