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.
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.
[^] # Re: Autres PEP de développeurs français
Posté par Victor STINNER (site web personnel) . En réponse au journal L'interpréteur de Python 3.4 sera plus interactif. É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/