Journal La durée de vie de Python 2.7 encore repoussée

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
22
14
avr.
2014

Bonjour Journal,

Python 2.7 a encore de beaux jours devant lui.

Sur la mailing list, Guido van Rossum employé maintenant par Dropbox ( qui emploie aussi Condoleezza Rice ) vient d'annoncer que Python 2.7 serait maintenue au moins jusqu'à 2020.

Being the last of the 2.x series, 2.7 will have an extended period of
-maintenance. The current plan is to support it for at least 5 years
+maintenance. The current plan is to support it for at least 10 years
 from the initial 2.7 release. This means there will be bugfix releases
-until 2015.
+until 2020.

Alors;

  • Est-ce une mauvaise nouvelle pour Python 3 qui malgré des gros effort de portage peine toujours autant à prendre le pas sur son petit frère ?
  • Vas-t-on voir apparaître un python 4 avant la mort de de Python 2.7 et avant le passage à l'âge adulte de Python 3 ?
  • Rien-à-carrer, Python 2.7 est bien meilleurs.

Sur le fil d'Hacker News, on peut également lire que l'entreprise Red Hat serait impliqué dans dans ce processus. Leur futur version RHEL 7 avec un support de 13 ans embarquera python 2.7 et sera maintenu jusqu'à 2027. Pour éviter de voir une autre version de python 2.7.made-in-Red-Hat avec les patchs de sécurité et deux, trois broutilles distribuée qu'avec RHEL 7, Python se propose de maintenir la branche 2.7 pour recevoir les éventuelles mises à jour.

Finalement, il ne semble n'y avoir pas grand chose de vraiment intéressant.

Désolé !

  • # orthographe et journal précédent!

    Posté par  (site web personnel) . Évalué à 0. Dernière modification le 14 avril 2014 à 15:36.

    • On a un peu posté en même temps. Du coup, un peu de rétro-action vers son journal plutôt que vers un site extérieur (même si j'aime bien pc impact) serait sans doute profitable pour mieux scinder la conversation.

    • au début, je pense qu'on dit : "vient d'annoncer que Python 2.7 sera maintenu au moins jusqu'en 2020."

    • vers la fin, "serait impliqué**e** " semble plus français.

    La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

  • # Standard de fait?

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,

    Peut on imaginer que les "poids lourds logiciels" se coordonnent pour sortir des versions long term support correspondante aux dates de sorties de RHEL?
    par poids lourd logiciel j'entends :
    - Python
    - SQL
    - Kernel linux
    - Java…

    Cela me semble peut probable, car cela demande un effort conséquent.
    Le choix d'aligner les versions long tem support sur Red hat est moyennement surprenant, vu son utilisation dans le monde industriel, mais une telle durée de vie permet telle de profiter pleinement des avancées faites entre temps?

    • [^] # Re: Standard de fait?

      Posté par  . Évalué à 5.

      Certains y ont déjà penser, ils ont eu des problèmes.

      Plus sérieusement, les LTS du noyau correspondent (pour une raison mystérieuse (sans doute un coup des illuminatis) aux versions du noyau dans la RHEL.

      « 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: Standard de fait?

        Posté par  (site web personnel) . Évalué à 3.

        Plus sérieusement, les LTS du noyau correspondent (pour une raison mystérieuse (sans doute un coup des illuminatis) aux versions du noyau dans la RHEL.

        C'est plutôt l'inverse, Red-Hat s'arrange pour prendre les versions du noyaux LTS qui sont supportés par la Linux Foundation et non des employés Red-Hat. Donc ce n'est pas Linux Foundation qui le fait exprès, mais le chapeau rouge qui choisi le noyau dans la bonne fenêtre (comme il y en a toujours 1 en cours, ça passe).

        Notons que Red-Hat patch énormément les paquets qu'il supporte. Le noyau typiquement peut recevoir des ajouts qui viennent de noyaux supérieurs si cela améliore le support des pilotes modernes (le noyau devant tenir 10 ans, il faut bien supporter le matériel durant ce laps de temps même celui qui n'existe pas encore) ou encore ce qui améliorera le support de la virtualisation par exemple.

        • [^] # Re: Standard de fait?

          Posté par  (site web personnel) . Évalué à 1.

          Le noyau typiquement peut recevoir des ajouts qui viennent de noyaux supérieurs si cela améliore le support des pilotes modernes (le noyau devant tenir 10 ans, il faut bien supporter le matériel durant ce laps de temps même celui qui n'existe pas encore)

          Plus ou moins. pour patcher le noyau, c'est 5,5 à 6,5 ans "seulement", pas 10 ans.
          "Native hardware enablement is provided by backporting hardware drivers, etc., to the relevant version of Red Hat Enterprise Linux. Production 1: Native. Production 2: Limited Native" (ensuite tu te démerdes avec la virtualisation)
          (source)

      • [^] # Re: Standard de fait?

        Posté par  (site web personnel) . Évalué à 10.

        Plus sérieusement, les LTS du noyau correspondent (pour une raison mystérieuse (sans doute un coup des illuminatis) aux versions du noyau dans la RHEL.

        Parse error!

        https://xkcd.com/859/

        Prochainement, je vous proposerai peut-être un commentaire constructif.

    • [^] # Re: Standard de fait?

      Posté par  . Évalué à 3.

      SQL

      Il y a plusieurs SQL la norme n'est pas implémentée par tous les SGBD, généralement on écris du SQL pour Oracle/Postgre ou pour MySQL/MariaDB ou pour les autres (par exemple pour gérer les dates).

      Java

      Oracle faire ça ? J'en doute, à moins que RH paie chère.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # ahah

    Posté par  . Évalué à 1.

    l'effet perl 5 :-)

    • [^] # Re: ahah

      Posté par  . Évalué à 6.

      L'effet XP.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

    • [^] # Re: ahah

      Posté par  . Évalué à 3.

      Perl 6 n'est pas encore sortie si je ne m'abuse (du moins l'interpréteur de référence sur la VM Parrot)…

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: ahah

        Posté par  (site web personnel) . Évalué à 1.

        Pas vraiment, mais ça avance on dirait. Rakudo aura bientôt trois backends : Parrot, MoarVM, et la JVM. Le plus prometteur semble être MoarVM ces derniers temps.

        Mais de toute façons, la différence c'est que perl5 et perl6 n'ont pas exactement les mêmes objectifs, ni les mêmes utilisateurs, malgré le fait qu'ils aient le même nom, donc il n'y a pas vraiment le même problème qu'avec python.

        • [^] # Re: ahah

          Posté par  . Évalué à 5.

          Pas vraiment, mais ça avance on dirait. Rakudo aura bientôt trois backends : Parrot, MoarVM, et la JVM. Le plus prometteur semble être MoarVM ces derniers temps.

          Sérieusement, ils peuvent pas essayer de sortir quelque chose avant de s'éparpiller ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: ahah

            Posté par  (site web personnel) . Évalué à 1.

            C'est vrai que ça s'éternise un peu, on va dire que c'est peut-être preuve d'une certaine flexibilité de l'architecture de Rakudo que de réussir à avoir trois backends. Et je ne suis pas sûr que se concentrer sur Parrot aurait vraiment accéléré les choses : c'est même plutôt rassurant de voir qu'ils se concentrent surtout sur MoarVM ces derniers temps, qui est une machine virtuelle faite spécifiquement pour perl6, sans être aussi ambitieuse que Parrot. Ils ont même commencé à faire quelques optimisations… peut-être qu'ils vont finalement nous sortir quelque chose un de ces jours ;)

  • # Quoi apprendre/choisir

    Posté par  . Évalué à 4.

    Du coup pour ceux qui veulent se lancer dans l'apprentissage du Python et/ou le choisir une version pour faire un nouveau programme, quel est le choix le plus pertinent ?

    --2.7 du fait de son poids, de son support, des nombreuse lib dispo ?
    --3.0 pour ses avantages, sa durée de vie potentiellement plus longue ?

    Commencer par 2.7 puis passer en 3.0 semble faisable même si un effort est nécessaire.
    Régresses de 3.0 en 2.7 me semble beaucoup plus difficile et pas vraiment pertinent.

    • [^] # Re: Quoi apprendre/choisir

      Posté par  . Évalué à 3.

      Je crois avoir entendu plusieurs projets dire qu'ils sont compatibles avec les deux (enfin avec 2.7 et une version particulière de la branche 3 genre 3.3 ou 3.4). Je sais pas si les nouveaux développement ne pourraient pas être compatible avec les deux versions. On doit pouvoir avoir une petite couche d'abstraction (pour ne pas appeler directement print par exemple) et lors du lancement de l'application charger le bon backend en fonction de la version de l'interpréteur.

      Ce que je dis est saugrenu ?

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Quoi apprendre/choisir

        Posté par  . Évalué à 7.

        On peut utiliser from __future__ import ... pour avoir du code compatible entre les version 2.7 et 3.x de Python. Par exemple, le code suivant fonctionnera aussi bien en Python 2.7 qu'en Python 3.x :

        from __future__ import print_function
        print("Hello Word!")

        C'est assez pratique pour utiliser les nouvelles fonctionnalités de Python 3.x tout en gardant la possibilité d'utiliser des libs restées en 2.x. Et en bonus, notre code est utilisable par beaucoup de monde.

    • [^] # Re: Quoi apprendre/choisir

      Posté par  . Évalué à 9.

      Au vu des capacités bien meilleures et tout ce qui va encore arriver dans python 3, je ne pense pas qu'il soit pertinent de débuter avec python 2.

    • [^] # Re: Quoi apprendre/choisir

      Posté par  (site web personnel) . Évalué à 6.

      Salut,

      je conseil python3 sauf si tu as une dépendance forte sur une lib python2.7 only. Si elle est aussi compatible python3 alors ne te pose pas la question. Si tu dois rester sur python2.7 alors je te conseil d'importer au début

      from __future__ import (division, absolute_import, with_statement,
                        print_function, unicode_literals)

from future_builtins import map, filter, zip, ascii, hex, oct

      Tu auras alors pour l'interprétation de ton module un langage s'approchant de python3

    • [^] # Re: Quoi apprendre/choisir

      Posté par  . Évalué à 4.

      Python 3 sans le moindre doute. Le langage a été un peu nettoyé, le support unicode est bien meilleur, et un très grand nombre de bibliothèques majeures est maintenant compatible.

      (mais ce n'est pas Python 3.0 qu'il faut choisir mais bien Python 3.4 :-))

      HS : ouhlala, ça devient compliqué le système de notation de Linuxfr ! C'est conçu par un core développeur Perl ?

      • [^] # Re: Quoi apprendre/choisir

        Posté par  (site web personnel) . Évalué à 3.

        Je vote pour Python 3 également. Après, on peut se contenter de Python 3.3, voire 3.2 (seule version 3 dispo sur Debian Wheezy, par exemple).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.