IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Python 2.7.11 est disponible avec des correctifs de bogues
Mais sans nouvelles fonctionnalités

Le , par Olivier Famien

797PARTAGES

5  0 
Python 2.7.11 est disponible et pour cette version, aucune nouvelle fonctionnalité n’a été mise en œuvre. Seules les corrections de bogues ont été effectuées. Nous avons entre autres les erreurs suivantes qui ont été corrigées :

  • HTTPConnection.request() n’était pas compatible avec les vieux styles de classes tels que TemporaryFile. Cela a été corrigé ;
  • un débordement d’entier a été découvert dans l’itérateur. L’erreur a été également corrigée ;
  • format(int, 'c') générait une erreur d’exception de type OverflowError lorsque l’argument n’est pas compris dans la plage de données (0, 256) ;
  • la vérification de type d’exception dans les gestionnaires d’erreurs standard comportait un bogue ;
  • une baisse de performance de l’interpréteur a été observée. C’est pourquoi il a été recommandé d’utiliser la syntaxe « computed gotos » pour envoyer les bytecodes dans l’interpréteur. L'application de cette recommandation permet d’accroître les performances de l'interpréteur ;
  • lorsque Python est exécuté avec l’option -3, les méthodes encode() et decode() et les constructeurs de str ainsi que les classes unicode et bytearray comportaient des erreurs d’encodage pour les caractères non-textes obsolètes. Un avertissement a été intégré toutes les fois que ces erreurs sont rencontrées ;
  • les opérations NAN étaient mal gérées à la compilation ;
  • plusieurs bogues ont été trouvés dans le décodage UTF-7 des données mal formées ;
  • une perte de mémoire a été détectée dans la méthode SSLSocket.getpeercer() ;
  • le protocole SSLv3 marqué comme vulnérable a été désactivé par défaut à la création de la classe ssl.SSLContext ;
  • le module sur les systèmes de fichiers ne supportait pas le décompte de liens pour les répertoires ;
  • le constructeur et la mise à jour de méthode de weakref.WeakValueDictionary n’acceptait pas l’argument self ;
  • un débordement de la mémoire tampon a été détecté dans le module imageop ;
  • le module tarfile ne tolérait pas un nombre de champs composés uniquement d’espace blanc. C’est maintenant le cas.


Ces corrections de bogues bien qu’utiles pour les utilisateurs des versions 2.x poussent certaines personnes à dire que l’équipe de Python serait plus tournée vers la version 3.x que cette dernière itération en raison de l’absence de nouvelles fonctionnalités. D’autres, pour leur part, enfoncent le clou en appelant de tous les vœux l’abandon complet du support de Python 2.x afin de se concentrer sur les versions 3.x.

En tout état de cause, l'équipe de Python a déjà averti que la branche 2.7 serait la dernière version de la série 2.x. Toutefois, un support Long Term Support (LTS) a été prévu pour cette branche. La maintenance de la version 2.7 sera donc effectuée jusqu'à 2020. En attendant cette date butoir, les développeurs utilisant les versions 2.x s’accrochent à cette branche et espèrent voir de nouvelles fonctionnalités dans leur version privilégiée.

Source : Python News

Et vous ?

Que pensez-vous de cette version de Python 2 ?

Pensez-vous qu’il serait temps pour les développeurs Python de tous migrer vers la version 3 ?

Voir aussi

Forum Python

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Tagashy
Membre confirmé https://www.developpez.com
Le 14/03/2018 à 12:38
Perso je développais en python 2 et je passe en python 3 depuis 1 ans (environ).
Du coup mon retours d’expérience:
pour des nouveaux projet faire du python 2 ou 3 c'est kiff kiff
par contre ils ont changé des choses en internes :
les str python 2 sont des byte[]
la ou en python 3 ce sont des unicodes.
ET ca mine de rien c'est un des plus gros problèmes.
Beaucoup de lib scientifique utilisais des str comme tableaux de chr ou assimile mais maintenant ca ne marche plus du coup il faut réécrire les libs. certes il existe des outils comme 2to3 mais il sont insuffisant vue que python est extrêmement libre au niveau du codage ce genre d'outil ne marche pas (ex call de méthode privé d'un objet en étant hors du contexte de l'objet, ajout de fonction/méthode en live, code oû les variable sont généré après avoir catch exceptions, rien que récemment j'ai vue un code qui faisais des import juste après avoir fait un sys.path.insert(0, './routes'), du coup comment un outils pourrais comprendre ce qui ce passe en interne pour convertir a du python 3)

Le gros problème aux passage à python 3 c'est pas le langage c'est les libraires qui ne veulent pas se convertir aux 3 ou qui trouve ça trop longs.
Du coup je suis pour cet arrêt de support, si les gens sont trop con pour pas suivre les évolutions , il faut les prendre par la peaux des fesses et leur dire arrêter vos connerie, vous suivez l’évolution des techno ou vous vous barrez.
lorsqu'on doit faire un docker avec python 2 et python 3 et faire des subprocess.call("python2 prog.py" car la librairie ne marche pas en python 3 on pense marché sur la tête.

et puis les nouveauté de python 3 sont quand mème pratique ... rien que le typage des variable c'est cool pour documenter (oui c'est que de la doc mais ça aide énormément avec un IDE derrière)
7  0 
Avatar de calvaire
Expert confirmé https://www.developpez.com
Le 30/12/2019 à 9:20
je suis passé rapidement a python3.x... mais jusqu'a aujourd'hui ce langage m'a toujours gonflé a cause de existence de ces 2 versions :
Distrib linux qui utilise python2 par défaut (j'ai eu beaucoup de difficulté parfois avec des clients ou j'ai du réécrire mon code en python2 parce qu’ils ne pouvaient pas installer python3)
Documentation sur le net ou faut faire attention a chaque fois que c'est bien du python3 (heureusement c'est de moins en moins le cas avec les années)
Des libs qui n'existe plus ou alors des imports a modifier
...

Don la fin du support de python2.7, cela veux dire que les distrib linux vont devoir migrer 100% de leurs scripts et ne plus installer par défaut python2, je suis content... j'aurais aimer que cette fin de support arrive plus tot (disons en 2015)

bon débarra python2, repose en paix... vers silverlight
8  3 
Avatar de stardeath
Expert confirmé https://www.developpez.com
Le 30/12/2019 à 13:19
Citation Envoyé par Olivier Famien Voir le message
Pour AlexMax, si l’équipe de développement de Python a reporté la première date de fin du support de Python 2.7, et s’il existe encore une forte population qui continue à utiliser Python 2.7, c’est parce qu’il n’y a pas suffisamment d’éléments motivants qui poussent à la migration vers Python 3. Au lieu de travailler à ces lacunes en implémentant de nouvelles fonctionnalités dans Python 3 pour convaincre les développeurs à migrer vers cette version, l’équipe de Python a plutôt agité le bâton en rappelant à chaque fois l’imminence de l’abandon de Python 2.x. Résultat, certains développeurs estiment qu’ils pourraient se tourner plutôt vers d’autres langages.
ça c'est encore une bonne excuse pour ne pas migrer : "il n'y a pas 100% des trucs que je veux dans python 3 (mais qui de toute façon n'était pas là dans python 2) donc je migre pas".

je suis d'accord avec calvaire, python 2 aurait du être mis de coté il y a au moins 10 ans. les gens/entreprises/etc trouveront toujours une bonne excuse pour pas le faire, ils n'ont toujours pas compris les risques à s'y prendre trop tard, qu'ils assument au bout d'un moment.

ps: en relisant c'est encore pire que ce que je pensais :

"la représentation fondamentale des chaînes de caractères a changé pour le pire et non le meilleur ;;" dans python 3 des données sont des collections d'octets et des chaînes de caractères sont des collections de ... caractères, en quoi c'est pire qu'avant où les données étaient des chaînes de caractères? et maintenant on a la prise en charge correcte d'unicode, enfin je ne suis plus obligé d'utiliser une verrue dans mon code pour accéder à des fichiers avec des caractères funkies.

"la gestion des paquets était et demeure un cauchemar en utilisant une combinaison d’environnements virtuels pip pour installer les dépendances spécifiques au projet ;;" ça n'a donc pas changé, je vois pas pourquoi imputer ça à python 3 ...

"comparé à d’autres langages, Python 3 est toujours lent, car il ne valoriserait que la simplicité par convention ;;" pareil, ça se plaint que python 3 a changé trop de trucs, mais là que ça n'a pas changé, ça se plaint pareil ..., en plus tu fais du python pour sa simplicité d'écriture avant tout (enfin je pense), ou alors la personne ne sait pas choisir un langage

"la bibliothèque asyncio permettant d’écrire du code concurrent en utilisant la syntaxe async/await aurait été ajoutée assez tardivement ;;" et donc? c'est tardif donc on migre toujours pas?

"des indications de type ont été ajoutées au langage en s’appuyant uniquement sur des analyseurs statiques de type hinting au lieu de créer également des vérifications de type d’exécution dans le langage, ce qui aurait été beaucoup plus utile et cohérent, selon l’intervenant ;;" toujours pareil, ça reste du python, tu peux pas reprocher à la fois de trop changer et de ne pas assez changer, sinon autant faire un nouveau langage, ça aurait râler pareil néanmoins.

"jusqu’à présent, il n’y a toujours pas de fonctions lambda anonymes multilignes." pareil que ma première version du post, "il n'y a pas 100% des trucs que je veux donc je migre pas"

bref, j'ai la flemme de trouver une conclusion à ce merdier...
7  2 
Avatar de Thomas404
Membre actif https://www.developpez.com
Le 30/12/2019 à 17:22
Tant mieux, cette situation avec 2 versions existantes etait ridicule, et moi je l'aime bien python 3.7
6  1 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 08/12/2015 à 11:19
=> Que pensez-vous de cette version de Python 2 ?
Il est toujours bien d'avoir des correctifs, même sur de vieille version d'un environnement comme Python.

=> Pensez-vous qu’il serait temps pour les développeurs Python de tous migrer vers la version 3 ?
Il est plus que temps, oui.

Mais les premiers acteurs sont les OS à montrer l'exemple:
  • Mac OS X: Python 3 n'est pas installé par défaut
  • Linux: La majorité des distributions utilisent Python2 comme interpréteur Python par défaut et non Python3 même si celui-ci est installé.


Ensuite, certain package de base ne sont pas toujours disponible pour Python3, je pense en particulier à "lxml" qui n'est pas disponible sur "pypi.python.org" en version compiler pour Windows pour Py3.
La communauté Python a aussi du travail dans ce sens pour faire accepter plus largement cette version.

Enfin, il serait aussi bon que dans lycées, les universités et les grandes écoles, les professeurs arrêtent de parler de Python 2.x et qu'ils promeuvent aussi Python 3.x qui apporte quand même un confort de développement non négligeable (juste l'unicode et la gestion des encodages est un argument suffisant pour cela).

On va me dire, "oui, mais Python est aussi beaucoup utilisé par des scientifiques qui ne s'y connaissent pas bien en informatique".
Et bien justement, s'il ne sont pas au top avec les outils de développement, qu'ils utilisent Python 3, ils ne s'en porterons pas plus mal (voir même mieux)
4  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 10/09/2019 à 12:04
Un exemple que je j'ai bien suivi est le langage Rust : il a mis en place un changement de syntaxe en 2018. Python et Perl ont clairement fait figure d'exemple à ne pas suivre lors des discutions sur la stratégie à adopter.
Leur solution finale a consisté à laisser chaque crate (l'équivalent du paquet) choisir l'édition qu'elle utilise(2015 ou 2018). Le compilateur est capable de compiler les deux éditions et les crates de différentes éditions peuvent interagir de manière totalement transparente.
Si l'édition n'est pas spécifiée c'est l'édition 2015 qui est employée, ainsi les anciennes crates continuent de fonctionner de manière totalement transparente, cependant l'outil qui crée les nouvelles crates définit par défaut la version à 2018.

J'ai moins suivi leur cas, mais il me semble que Go et Swift ont mis en place eux aussi des changements majeurs sans diviser lourdement leurs utilisateurs.
4  0 
Avatar de RPGamer
Membre averti https://www.developpez.com
Le 30/12/2019 à 0:29
Passage déjà fait depuis longtemps et sans grande difficulté. Sans regret, adieux Python 2.
5  1 
Avatar de gallima
Membre averti https://www.developpez.com
Le 14/03/2018 à 13:37
Un changement dans les types de données (str / byte[]) fondamentaux, c'est une grosse brisure qui peut impliquer beaucoup de ré-écriture.
La solution est peut être plus simplement de changer de langage, surtout dans les nombreux cas où python n'était qu'une couche d'encapsulation.
3  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 14/03/2018 à 13:51
Citation Envoyé par VinsS Voir le message
ces modules tiers qui ne tournent pas encore sous Python 3 sont, aujourd'hui, à considérer comme abandonnés.
Ce n'est pas parce qu'un module développé sous Python 2 n'a plus de mise à jour qu'il est à jeter à la poubelle.
Certains modules sont complets, et ne nécessitent aucun rajout.
Le seule souci est en effet que personne ne les porte sous Python 3 et que le créateur ne donne plus signe de vie.
Sauf que quand on a de la production qui tourne avec ce genre de chose et qu'on a pas l'équipe faite pour porter la librairie... Bah on continue bon gré malgré sous Python 2.

La richesse de Python c'est ses librairies.
Et malheureusement c'est ce qui lui fait aussi le plus mal depuis l'écart entre Python 2 et Python 3.

Note : je fais parti des méchants petits canards qui utilisent Python 2.7 et qui continueront à l'utiliser.
3  0 
Avatar de tyrtamos
Expert éminent https://www.developpez.com
Le 15/03/2018 à 10:40
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...
3  0