Journal L'interpréteur de Python 3.4 sera plus interactif

Posté par  . Licence CC By‑SA.
Étiquettes :
23
2
oct.
2013

En regardant les nouveautés de la prochaine version de Python prévue pour février 2014, dans la section Other improvements j'ai pu lire que la console de Python aura le complément avec la touche Tab activé par défaut. Il ne sera plus forcément obligatoire d'installer une autre console pour avoir quelque chose d'un peu utilisable. Je me demande d'ailleurs si une coloration syntaxique est prévue à plus long terme.

C'est donc un vœux datant d'avril 2009 qui est exhaussé par Antoine Pitrou_< et Éric Araujo.

Pour continuer dans le cocorico, une grosse contribution de la part de Victor Stinner_< (PEP 446) fait également son entrée dans le code de Python.

J'espère qu'ils nous en parlerons dans la dépêche concernant cette version 3.4.

Puisque que l'on parle d'interpréteur Python, IPython vient de recevoir une donation de 100 000 $ de la part de Microsoft via NumFOCUS. Cette donation est, par ailleurs, sans engagement ce qui offre la possibilité aux développeurs de dépenser cette somme comme bon leur semble.

  • # multithread

    Posté par  . Évalué à 3.

    ils ne peuvent pas donner 10 000$ au projet python pour un vrai support du multithreading?

  • # Autres PEP de développeurs français

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

    "Safe object finalization", Antoine Pitrou
    http://www.python.org/dev/peps/pep-0442/

    "Add new APIs to customize Python memory allocators", Victor Stinner
    http://www.python.org/dev/peps/pep-0445/

    3/6 (50%) des PEP déjà acceptées dans Python 3.4 ont été écrites par des développeurs français ;-)

    La PEP 445 est assez abstraite, elle sert juste à préparer le terrain pour la PEP 454 qui propose d'ajouter un module pour tracer les allocations mémoires. Je bosse dessus, pas sûr que ça soit finit avant Python 3.4 :
    http://www.python.org/dev/peps/pep-0454/

    • [^] # Re: Autres PEP de développeurs français

      Posté par  . Évalué à 2.

      Il reste un peu plus d'un mois pour la finaliser avant le gel des fonctionnalités avec la 1ere  Beta, tu penses que c'est jouable ?

      • [^] # Re: Autres PEP de développeurs français

        Posté par  . Évalué à 4.

        Si on arrive à intégrer tulip (PEP 3156), on devrait arriver à intégrer le travail de Victor…
        Victor, d'ailleurs ça me rappelle que je dois revoir ta PEP, je vais essayer de m'y mettre cette semaine !

      • [^] # Re: Autres PEP de développeurs français

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

        Il reste un peu plus d'un mois pour la finaliser avant le gel des fonctionnalités avec la 1ere Beta, tu penses que c'est jouable ?

        Je viens de poster la 3e version de ma PEP "tracemalloc". Je considère que la PEP a atteint l'étape "version finale qui mérite d'être relue". L'API est beaucoup plus sympa maintenant, dumoins je l'espère.

        http://www.python.org/dev/peps/pep-0454/

        L'implémentation est déjà écrite, elle est complète et fonctionnelle. Je l'ai testée sous Windows, Linux et FreeBSD : aucun soucis.

        Le problème est de trouver quelqu'un pour relire la PEP, trouver les erreurs, proposer des modifications, puis finalement la valider.

        De toute manière, je compte backporter l'implémentation de cette PEP pour Python 2.5-3.3.

        Si la PEP rate le coche pour Python 3.4, il sera quand même possible d'utiliser le module pytracemalloc dispo sur le cheese chop (pypi.python.org) sans avoir à recompiler Python (je suis en train de bosser sur le backport). J'ai écrit la PEP 445 pour éviter d'avoir à recompiler Python pour utiliser tracemalloc.

    • [^] # Re: Autres PEP de développeurs français

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

      Et si on rajoute en plus les PEP où Antoine contribue fortement sous forme de commentaires et revues, plus ceux où il est PEP Dictateur, plus les autres contributeurs français, on peut dire que les français font avancer Python à grand pas !

      Victor, je voulais d'ailleurs te dire mon respect pour plonger dans les sujets aussi tordus que ceux que tu abordes (unicode à tous les étages, héritage des descripteurs, etc), qui demandent vraiment d'aller creuser tous les cas tordus dans toutes les plate-formes. C'est un travail de fourmi, avec très peu de retombées visibles, qui rendent pourtant Python beaucoup plus solide.

      Un merci à toi et autres contributeurs.

      Philippe (fan de python-dev)

      • [^] # Re: Autres PEP de développeurs français

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

        Victor, je voulais d'ailleurs te dire mon respect pour plonger dans les sujets aussi tordus que ceux que tu abordes (unicode à tous les étages, héritage des descripteurs, etc), qui demandent vraiment d'aller creuser tous les cas tordus dans toutes les plate-formes. C'est un travail de fourmi, avec très peu de retombées visibles, qui rendent pourtant Python beaucoup plus solide.

        Pour Unicode, les retombées visibles sont la baisse significative des rapports de bug liés à Unicode dans Python 3.3. Autrement dit, "juste ça marche" : Python s'occupe de choisir l'encodage comme un grand.

        Pour la PEP 418 (time.monotonic), c'était une longue bataille sur des détails qui était assez éprouvante. Mais j'ai gagné : Python 3.3 a une fonction time.monotonic(), ouf ! C'était pénible d'avoir à sortir ctypes juste pour avoir accès à une horloge monotone sur chaque projet.

        http://www.python.org/dev/peps/pep-0418/

        Pour la PEP 446 (non-inheritable files/sockets), honnêtement, je ne sais pas vraiment pourquoi je me suis battu (seul contre tous) pendant plusieurs mois pour faire passer l'idée qu'il fallait tout pêter.

        Je crois qu'initialement, c'était un rapport de bug qui disait que open("document.txt", "re") ne fonctionnait plus dans Python 3. J'ai horreur des régressions Python 2 => Python 3, alors je me suis intéressé au but. Le bug était un effet de bord de l'implémentation de Python 2 : file utilise fopen() en interne, et la GNU libc a ajouté un nouveau flag "e" qui crée un fichier non inhéritable.

        Bref, au final, personne ne devrait remarquer ce changement majeur. Mais ce changement a fermé une bonne dizaine de tickets dans le bug tracker, et évite des race conditions particulièrement pénibles à diagnostiquer et à corriger.

        http://www.python.org/dev/peps/pep-0446/

        • [^] # Re: Autres PEP de développeurs français

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

          C'est bien ce que je dis: un bug, quelques semaines de dev, deux fois plus les tests et lire la doc, et encore deux fois plus pour en discuter sur Python-dev. Et au final, une PEP, pour un truc où 99.99% des gens ne sauront jamais qu'il y avait eu un problème avant. Respect!

          Ce que je trouve intéressant en suivant python-dev, c'est qu'on voit d'une part l'attachement très fort des développeurs à ne rien casser (j'imagine qu'ils en ont mangé pas mal par le passé), d'autre part on voit la réflexion de fond sur le long terme et l'attention à chaque détail. On arrive d'ailleurs toujours à la conclusion (sur des fonctionnalités pointues) qu'à un moment, Python ne peut pas résoudre tout et les problèmes de l'OS ou les différences de fonctionnement des OS en dessous finissent par se voir. Ca s'est vu sur la clock monotonic, sur l'unicode ou sur l'héritage des file descripteurs.

          J'aime aussi beaucoup lire le travail de cette communauté: les développeurs sont globalement très moteurs, acceptent les critiques et sont prêts à se remettre en question, même quand le travail est en amont est très conséquent.

          On pourrait parfois penser que Python est assez complet et très stable, mais il y a toujours des propositions d'évolutions très importantes.

          Bref, du beau boulot !

  • # Packaging ...

    Posté par  . Évalué à 3.

    Je profite de la présence de nos stars françaises pour avoir quelques nouvelles sur le packaging de Python.
    A une époque, la 3.3 devait arriver avec un module dédié au packaging et ce dernier a été retiré car il n'était pas suffisamment sec.
    Est ce que quelque chose est prévu là-dessus dans le 3.4 ?
    Merci.

    PS: J'ai trouvé quelques infos ici https://python-packaging-user-guide.readthedocs.org/en/latest/future.html

    • [^] # Re: Packaging ...

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

      Est ce que quelque chose est prévu là-dessus dans le 3.4 ?

      En bref : non.

      Il y a une nouvelle PEP toute fraîche proposant d'intégrer un truc pour bootstrapper pip :
      http://www.python.org/dev/peps/pep-0453/

      Je crois que le projet "distutils2" (ou "packaging" pour son nom quand il était question de le mettre dans Python 3.3) tourne au ralenti, voir est mort. Les développeurs sont sûrement morts d'épuisement. Les efforts se concentrent plutôt sur distlib, une bibliothèque implémentant les nouvelles PEP liées au packaging, mais n'implémentant pas tout distutils. Si j'ai bien compris, distlib est une nouvelle bibliothèque (et non pas une modification de l'existant comme distutils), et devrait permettre de facilement implémenter une nouvelle bibliothèque distutils par dessus. Enfin, RTFM car je n'ai pas suivi le sujet (j'ai plutôt tendance à l'éviter !) :

      http://distlib.readthedocs.org/en/latest/

      Les projets setuptools et distribute se font fait des calins et ont fusionné dans setuptools. C'est déjà ça.

      Il y a plein de PEP liées au packaging, déjà acceptée ou en cours de discussion.

      Sinon, voir la liste distutils-sig pour les détails :
      https://mail.python.org/mailman/listinfo/distutils-sig/

Suivre le flux des commentaires

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