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 Stibb . Évalué à 3.
ils ne peuvent pas donner 10 000$ au projet python pour un vrai support du multithreading?
[^] # Re: multithread
Posté par Nonolapéro . Évalué à 3.
Dans l'entretien avec les développeurs Python (avril 2011), le multithreading ne semblait pas être vraiment un problème rédhibitoire et supprimer le GIL, au contraire, serait plus ennuyeux.
[^] # Re: multithread
Posté par Stibb . Évalué à 0.
ils ont tords. Le multithread est peut être compliqué à prendre en compte, mais absolument nécessaire pour un language qui se dit moderne. Ils ont sacrifié le support du multithread entre autre pour "que le code reste maintenable"…
[^] # Re: multithread
Posté par Victor STINNER (site web personnel) . Évalué à 6.
Le multithread est peut être compliqué à prendre en compte, mais absolument nécessaire pour un language qui se dit moderne.
Le GIL n'empêche pas d'avoir plusieurs threads s'exécutant simultanément :
http://www.haypocalc.com/wiki/Python#GIL
Ils ont sacrifié le support du multithread entre autre pour "que le code reste maintenable"…
CPython a été écrit il y a 20 ans, à l'époque les ordinateurs ayant plusieurs CPU/coeurs étaient très rare. La gestion de la concurrence a été implementée à base d'un verrou global, ce qui simplifie beaucoup l'écriture de code.
Changer la manière dont CPython gère la concurrence demande à peu près de réécrire tout le code (environ 478.000 lignes de code C). Je ne sais pas si remplacer un verrou global par de plus petits verrous seraient moins coûteux en temps de dev (que de toute réécrire). Et puis des tentatives précédentes avaient montré que les performances étaient moins bonnes avec de petits verrous (sur une application n'utilisant pas de thread).
Trent Nelson a proposé une approche différente :
http://python-notes.boredomandlaziness.org/en/latest/conferences/pyconus2013/20130313-language-summit.html#parallelizing-the-python-interpreter
Armin travaille sur encore une autre approche utilisant de la mémoire transactionnelle. Il travaille sur PyPy mais a dit qu'il serait envisageable de faire ça sur CPython. Exemple d'articles :
http://morepypy.blogspot.fr/2013/08/update-on-stm.html
http://morepypy.blogspot.fr/2013/06/stm-on-drawing-board.html
…
[^] # Re: multithread
Posté par wolowizard . Évalué à 2.
Sinon au passage il y a pypy et ses avancées ;)
http://za.pycon.org/talks/15/
[^] # Re: multithread
Posté par Stibb . Évalué à 1.
malheureusement ne supporte pas toutes les lib de python :(
# Autres PEP de développeurs français
Posté par Victor STINNER (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 Nonolapéro . É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 neologix . É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 barmic . Évalué à 3.
Je pense que ce serait intéressant de savoir comment s'organise les PEP (processus de création et de validation, comment ça se gère par rapport au versions de python qui sont time based (si j'en crois le journal qui parle d'une version pour février), à quoi elles servent (tous doit-il être défini par des PEP ?), éventuellement comparer vite fais avec les autres qui s'en rapproche (XEP, JSR),…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autres PEP de développeurs français
Posté par Nonolapéro . Évalué à 5.
Je pense que les explications des développeurs seront agréables à lire mais s'il faut commencer par quelque chose c'est bien la PEP sur les PEP, c'est-à-dire la PEP 1.
[^] # Re: Autres PEP de développeurs français
Posté par jihele . Évalué à 4. Dernière modification le 03 octobre 2013 à 10:57.
TL;DR
[^] # Re: Autres PEP de développeurs français
Posté par Victor STINNER (site web personnel) . Évalué à 4.
Je trouve le fonctionnement par PEP vraiment enrichissant. C'est un gros travail pour l'auteur d'une PEP, car il se prend plein de critiques dans la gueule, et surtout énormément de questions. Mais la confrontation apporte systématiquement un résultat d'une meilleure qualité.
PHP a d'ailleurs adopté un fonctionnement similaire sous le nom "RFC", je trouve ça super.
J'ai donné plusieurs présentations à Pycon FR où j'explique un peu comment Python est développé.
https://github.com/haypo/conf/tree/master/2009-PyconFR-Paris/contribuer
https://github.com/haypo/conf/blob/master/2011-PyconFR-Rennes/developpement_cpython/cpython.pdf?raw=true
https://github.com/haypo/conf/blob/master/2012-PyconFR-Paris/devprocess/process_dev_cpython.pdf?raw=true
[^] # Re: Autres PEP de développeurs français
Posté par Antoine . Évalué à 2.
Ah oui, ce serait bien que tu regardes sa PEP, ça me laissera plus de temps pour le reste :-)
[^] # Re: Autres PEP de développeurs français
Posté par Victor STINNER (site web personnel) . Évalué à 2.
Si on arrive à intégrer tulip (PEP 3156),
Hou là, Tulip, ce n'est pas gagné : Guido ne semble pas chaud pour finir ça avant Python 3.4 beta 1. J'espère que ce gros module ne va pas interférer avec ma PEP sans prétention :-)
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 !
Hey, mais c'est une excellente nouvelle ça ! Tu sembles être le seul motivé, Antoine est intéressé mais n'est pas disponible en ce moment.
Je peux même financer cette relecture en bière, je serai sur Paris du 14 au 18 octobre. Tiens, je serai aussi à Strasbourg le 26 pour Pycon FR 2013, j'y présente justement… le module tracemalloc :-)
http://www.pycon.fr/2013/
("Le programme devrait par ailleurs être en ligne dans le courant de la semaine.")
[^] # Re: Autres PEP de développeurs français
Posté par Antoine . Évalué à 2. Dernière modification le 04 octobre 2013 à 00:07.
Larry a dit qu'il était prêt à reculer un peu la beta 1 pour laisser le temps à Tulip (qui s'appellera finalement « asyncio ») de mûrir.
https://mail.python.org/pipermail/python-dev/2013-September/129077.html
En fait le cœur de l'API est à 90% stable, mais il y a plein de petits trucs à fignoler et clarifier. Ça tombe bien, Guido est à fond dessus :-)
[^] # Re: Autres PEP de développeurs français
Posté par Victor STINNER (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 Philippe F (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 Victor STINNER (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 Philippe F (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 sifu . É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 Victor STINNER (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.