Journal Python 3.1 devient la version de Python par défaut sur Archlinux

Posté par  .
Étiquettes : aucune
14
19
oct.
2010
Chers lecteurs,

Depuis quelques jours le dépot testing et depuis quelques heures sur les dépots core, extra et community de Archlinux sont passés de Python 2.6 à Python 3.1 comme version par défaut de Python.
Il me semble que c'est la première distribution à opérer ce changement, pour les personnes qui n'ont pas leur script maison ou leurs paquets compilés compatible avec python3, ils vont devoir appeler python2 pour que ça ne plante pas.

Je vous laisse le lien de l'annonce sur le site principal de Archlinux : http://www.archlinux.org/news/python-is-now-python-3/

Ainsi qu'un lien vers un billet d'un des développeurs de Archlinux parlant de cette transition : http://allanmcrae.com/2010/10/big-python-transition-in-arch-(...)

La mise à jour vient de se finir je me demande s'il y a eu de la casse sur mon système.

  • # argparse

    Posté par  . Évalué à 3.

    Dommage de forcer la montée de version alors que argparse ne sera porté qu'à partir de la 3.2.

    optparse étant considéré comme obsolète, ca veut dire que les utilisateurs de archlinus devront se passer de quelques nouveautés sauf à installer la lib en plus.
    Je ne suis pas impatient que les autres distribs les imitent.

    • [^] # Re: argparse

      Posté par  . Évalué à 6.

      ArchLinux n'a pas pour vocation d'être conservateur dans ces choix, mais plutôt d'être très à la pointe dans ces versions de logiciels (tout en restant très stable)

      C'est un choix, qui me plaît, mais du coup ça semble logique qu'ils mettent à jour assez vite les paquets s'ils jugent la stabilité suffisante. De toutes façons quand la version 3.2 de python sortira on la verra certainement très vite débarquer puisque le gros de la migration aura déjà été fait grâce à cette version 3.1.

      • [^] # Re: argparse

        Posté par  . Évalué à 4.

        La sortie de python 3.2 n'est pas prévu pour tout de suite si l'on s'en tient à la feuille de route : http://python.org/dev/peps/pep-0392/

        The current schedule is:

        * 3.2 alpha 1: August 1, 2010
        * 3.2 alpha 2: September 4, 2010
        * 3.2 alpha 3: October 9, 2010
        * 3.2 beta 1: November 13, 2010

        (No new features beyond this point.)

        * 3.2 beta 2: December 4, 2010
        * 3.2 candidate 1: December 18, 2010
        * 3.2 candidate 2: January 8, 2011
        * 3.2 final: January 22, 2011

      • [^] # Re: argparse

        Posté par  . Évalué à 6.

        Il me semble qu’il y a encore énormément de bibliothèques qui ne sont pas portées sous Python 3.

        Chez moi c’est la trilogie Numpy, Scipy et Matplotlib qui pose problème. Numpy 1.5 est la première version qui fonctionne avec Python 3, seulement le 31 août de cette année, mais la dernière version de Scipy date du 27 juillet, et matplotlib du 7 si j’en crois sourceforge.

        Ce ne sont pas seulement les scripts de l’utilisateur qui sont touchés dans ce cas, mais des bibliothèques qui peuvent être considérées, par certains, comme indispensables.

        • [^] # Re: argparse

          Posté par  . Évalué à 5.

          python 2 est encore disponible, c'est juste que ce n'est plus la version implicite.

          Donc tout ce qui n'est pas porté fonctionne encore et quand on lit le message pour tous les packages officiels ce passage a été géré (soit par migration vers la version supportée par python3 soit par modification python->python2)

          • [^] # Re: argparse

            Posté par  . Évalué à 1.

            Par contre j'ai remarqué un truc assez génant :
            les paquets officiels sont installés pour python3, mais si sur AUR un paquet v2 only demande une lib présente dans les paquets officiels utilisant python3 c'est bien relou.

            • [^] # Re: argparse

              Posté par  . Évalué à 1.

              Oui, il y a un travail à faire par la communauté pour régler tout ça :)

              J'ai commencé de mon côté avec les paquets que j'utilisais !

              • [^] # Re: argparse

                Posté par  . Évalué à 1.

                Il va donc falloir mettre à disposition 2x plus de paquets pour gérer les v2/v3 ?
                Exemple : sabnzbd

                Dépends de :
                python-yenc <- AUR, ok je change python par python2 dans le PKGBUILD

                Mais aussi de :
                python-cheetah
                python-feedparser
                pyopenssl

                qui sont tout les 3 installés depuis les packages.
                Python2 n'aura donc pas accès à ces librairies...

                • [^] # Re: argparse

                  Posté par  . Évalué à 1.


                  Mais aussi de :
                  python-cheetah
                  python-feedparser
                  pyopenssl

                  qui sont tout les 3 installés depuis les packages.
                  Python2 n'aura donc pas accès à ces librairies...


                  ces paquets utilisent python2, comme la plupart des paquets python dans les dépôts de arch. Il va juste falloir un peu de temps pour qu'ils soient renommés en python2-truc.

    • [^] # Re: argparse

      Posté par  . Évalué à 4.

      je vois pas le lien avec entre la nécessité d'attendre pour migrer et argparse?

      Si la version 3.1 ne contient pas toutes les nouveautés annoncées en 3.x ce n'est pas une raison pour attendre avant d'y passer.

      L'idée actuelle est de migrer les packages existants qui se reposent sur python 2.6/2.7 vers la version 3. Ce qui constitue déjà un travail très important.

      Quand la version 3.2 sortira le delta sera à ce moment moins important et justement, les développeurs auront certainement d'avantage de temps à consacrer à l'utilisation des nouveautés.

      Et comme tu le dis justement en plus, ce n'est déjà pas impossible d'utiliser argparse et depuis python 2.7 il est même dans les lib standards.

    • [^] # Re: argparse

      Posté par  . Évalué à 4.

      On pourrait aussi mettre sur le tapis les problèmes certains autres composant de la bibliothèque standard mais c'est complétement hors sujet :
      Archlinux est une distribution rolling release dont l'objectif est de fonctionner avec : les versions les plus à jour possible et des paquets le plus "vanilla" possible.

      Partant de là, c'est cohérent comme upgrade (c'est même un peu lent, python 3.1 étant out depuis quelques mois déjà).

  • # Et bien chez moi ....

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

    Cela a casser pas mal de chose ...

    Au revoir Pida (IDE sympa pour python) intégrant vim et autres appli Python meme après recompilation

    Je vais essayer de faire marche arrière.

    • [^] # Re: Et bien chez moi ....

      Posté par  . Évalué à 2.

      a priori ils ont renommé python en python26, donc peut-être que tu peux faire référence à cette version, voire un lien symbolique, pour faire fonctionner pida ?

      Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Et bien chez moi ....

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

        Si seulement mais en plus j'ai un passage pour python2 à python 2.7 en non plus python 2.6 ..

        Bref pas top tout cela ...

        Cela m'apprendra à faire des yaourt -Syu sans rien lire ..

  • # Comment faire au niveau des applications?

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

    Je me pose la question depuis un moment pour autojump: autojump est en python2 et va le rester pour un moment, parce que c'est la version qui est compatible avec le plus de systèmes. Problème, si je laisse le shebang comme il est actuellement, (#!/usr/bin/env python) autojump ne marchera plus sur arch.

    Sur arch, il y a bien un /usr/bin/python2, mais il n'est pas présent sur toutes les distributions, de loin. Que faire?

  • # <-- Hey, toi ! clique sur le [+] à gauche !

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

    ça va tout casser chérie !

    Par contre, Ruby 1.9, lui, est déjà bien supporté par la communauté et par quasiment toutes les librairies :p. Je dis ça, je dis rien.

    • [^] # Re: <-- Hey, toi ! clique sur le [+] à gauche !

      Posté par  . Évalué à 4.

      C'est vraiment pertinent de comparer un machin dont la nouvelle branche casse la compatibilité ascendante avec un autre dont le nouvelle version (branche != version, je précise) apporte des nouvelles fonctions.

      C'est vraiment pertinent de comparer de langage de programmation sur la base du packaging et du support dans les distributions.

      C'est vraiment pertinent de comparer le support par une distribution et celui par la communauté (oui évidement la communauté python ne supporte pas python 3 d'ailleurs je vais de ce pas créer un fork pour le faire savoir).

      C'est vraiment pertinent de comparer les quelques milliers (centaines ?) de librairies tierce parties pour Ruby et la dizaines de milliers pour Python.

      Bref, ton argumentaire est vraiment pertinent.

      • [^] # Re: <-- Hey, toi ! clique sur le [+] à gauche !

        Posté par  . Évalué à 0.

        C'est vraiment pertinent de comparer les quelques milliers (centaines ?) de librairies tierce parties pour Ruby et la dizaines de milliers pour Python.

        Tu te bases sur quoi pour dire ça ? Moi qui utilise les deux, j'ai plutôt l'impression que Python est souvent à la remorque de Ruby en ce qui concerne les librairies. Fudge qui s'inspire de Mocha, Fabric de Capistrano, etc., sans parler de tous les frameworks web qui reprennent les concepts de Rails... ah mais oui, nous y voilà, c'est la prolifération des frameworks web Python qui nous donne ces chiffres ;-) Par contre on attends toujours un outil à la hauteur de gem pour les gérer, toutes ces libs Python. Pip ne m'a pas vraiment convaincu.

        PS: je trouve Python tout à fait correct et je ne suis nullement un inconditionnel de Ruby, son gros défaut étant toujours sa lourdeur.

        • [^] # Re: <-- Hey, toi ! clique sur le [+] à gauche !

          Posté par  . Évalué à 2.

          Sur les ordres de grandeurs, il n'a pas tord. Python dispose de beaucoup plus de librairies extérieures que Ruby. Même si c'est difficile de donner des chiffres précis, ça semble assez coutumier de le penser et de le dire. (premier exemple sur google: http://c2.com/cgi/wiki?PythonVsRuby )

          Après tu es parti à comparer l'innovation ("à la remorque de...") de l'un par rapport à l'autre. C'est peut être plus subjectif comme critère. Tout comme la valeur de Pip Vs Gem et la comparaison de "lourdeur". Ce sont d'autres débats avec à mon avis des avis bien tranchés d'un coté et de l'autre ;-)

        • [^] # Re: <-- Hey, toi ! clique sur le [+] à gauche !

          Posté par  . Évalué à 2.

          > Tu te bases sur quoi pour dire ça ?
          Je suis d’accord avec lui, et je me base sur mon expérience. En tant que langage, je préfère Ruby, mais je suis souvent obligé de me rabattre sur Python à cause des libs de Ruby. En vrac :
          - Pas trouvé d’équivalent de lxml (aussi performant, avec un parser HTML capable de parser n’importe quelle page écrite avec les pieds, et avec une API aussi agréable)
          - Pas trouvé d’équivalent de feedparser
          - Librairie standard HTTP absolument déplorable (mauvaise documentation — j’ai du lire le code pour comprendre comment l’utiliser —, comportement différent de celui documenté et difficilement utilisable pour autre chose que request().body)

          Oui, il est vrai que Ruby a des libs que Python n’a pas. En pratique, pour mes projets, les problèmes sont toujours en sens unique.

          > Par contre on attends toujours un outil à la hauteur de gem pour les gérer
          Pas moi.
          Merci de laisser ma distrib gérer les paquets.

  • # Pendant ce temps là, avec Cygwin

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

    Toujours pas de version de Python 3 de base (à installer en parallèle de Python 2.6).
    (je sais, package le toi-même)

Suivre le flux des commentaires

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