Victor STINNER a écrit 1632 commentaires

Salut, je vais m'essayer au difficile exercice d'expliquer ce qu'est OpenStack. Je viens de rejoindre la société eNovance, on m'a pas mal expliqué comment ça marche :-) ( http://www.enovance.com/ : Youhou, eNovance recrute !)

À ce que j'en ai compris, le principe est de réutiliser des serveurs moyen de gamme et de considérer que le matériel n'est pas fiable. Le matériel est interchangeable, mais le logiciel doit toujours fonctionner. Les machines virtuelles peuvent par exemple migrer d'un serveur à un autre si la machine qui l'héberge pose problème. La machine peut alors être analysée, mise à jour, réparée, voir remplacée.

OpenStack n'impose aucune technologie : chaque brique est interchangeable. Exemple : les machines virtuelles peuvent être exécutée par KVM, LXC, Docker, ne pas utiliser de virtualisation (option "Bare Metal") ou encore plusieurs autres options. Pareil pour le réseau, on a le choix d'utiliser différents types de switch et routeur, matériels ou logiciels. Pareil pour les "block devices" (disque dur d'une machine virtuelle) : le stockage peut être local (sur le disque dur de la machine qui héberge la machine virtuelle) ou distribué (ex: DRBD, Ceph, iSCSI et une bonne dizaines d'autres options). Des solutions commet DRBD ou Ceph permettent de répliquer les données (sur au moins 3 machines différentes), toujours pour gérer les pannes et rester flexible sur le matériel.

Enfin, l'autre grand principe d'OpenStack est l'absence de limite matérielle. L'idée est de commencer petit, puis acheter (ou louer) du matériel quand le besoin augmente. Site web trop lent ? Hop, on rajoute quelques machines virtuelles avec de nouveaux serveurs MySQL. Stockage trop petit ? Hop, on rajoute des noeuds de stockage. Concrètement, les machines peuvent être hébergé dans sa propre entreprise (cloud privé) ou dans un data center où on paie ce qu'on utilise (cloud public).

OpenStack est conçu pour ne pas avoir de "single point of failure" et pour gérer de gros data center, plusieurs centaines de serveurs, voir plusieurs milliers. À cette échelle, rien ne doit être manuel : tout doit être automatisé. Créer une machine virtuelle ne doit pas nécessiter de taper une dizaine de commandes par SSH, mais juste de cliquer sur un gros bouton "Créer une VM Linux". La brique Heat ajoutée dans la version Havannah permet par exemple de créer et configurer de nouvelles VMs automatiquement en cas de forte charge.

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
…

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/

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/

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

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.")

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.

"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/

C'est quoi un langage libre ou open-source ?

Java est plutôt perçu comme un langage fermé car Oracle, et anciennement Sun, impose de nombreuses contraintes et n'est pas ouvert à la discussion. Exemples :

• Une JVM ne peut pas être publiée si elle ne passe pas la lourde suite de tests (je ne connais pas les détails), ou bien c'est juste une restriction sur le nom "Java" ? Sun a par exemple intenté un procès à Microsoft parce que sa JVM ne respectait pas les spécifications ! http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine#Sun_vs._Microsoft
• Sun/Oracle est vraiment en position dominante pour décider de l'évolution du langage, la fondation Apache s'en est plaint à plusieurs reprises
• La licence de "Java" (JVM, bibliothèque standard, compilateur, etc.) n'était (n'est ?) pas libre

Quelques articles linuxfr qui en parlent :

http://linuxfr.org/news/discussion-entre-apache-et-sun-sur-lopen-source-un-happy-end
http://linuxfr.org/news/jspa-sun-vs-apache-1-0
http://linuxfr.org/news/apache-software-foundation-et-oracle-le-divorce-autour-de-java

Des craintes similaires ont été formulées au sujet de Microsoft C# et plus généralement Microsoft .NET.

Au contraire, les langages Perl, PHP et Python sont perçus comme libre car leur implémentation de référence est publiée sous une licence libre, les spécifications sont ouvertes, et surtout n'importe qui peut suggérer une modification, puis l'implémenter.

Pour Python, il y a une liste de discussion python-ideas, puis la liste des propositions d'améliorations de Python (PEP) :

http://mail.python.org/mailman/listinfo/python-ideas
http://www.python.org/dev/peps/

Pour PHP, il existe les RFC :

https://wiki.php.net/rfc

Salut, j'ai codé une bibliothèque de génération de nombres aléatoires : https://bitbucket.org/haypo/hasard

Le projet vient avec des outils permettant de stocker la sortie d'un générateur dans un fichier, puis d'analyser les données. Il y a des outils pour générer une image ( c'est rigolo avec des générateurs tout pourri genre celui de PHP sous Windows, http://boallen.com/random-numbers.html ), test de la distribution avec les outils ENT et DieHarder, calcul d'entropie, calcul de la période, etc.

Hasard vient avec une suite de tests unitaires. Il choisit comme un grand le meilleur générateur et la meilleure source d'entropie (pour initialiser le générateur) selon le profil demandé (vitesse ou sécurité). Hasard réutilise les générateurs existants (API Windows, /dev/urandom, OpenSSL, gcrypt, etc.)

J'avais remarqué qu'OpenSSL n'injecte pas d'entropie (RAND_add) lors d'un fork. Du coup, deux processus fils ayant le même pid vont générer les même nombres. Ça peut arriver avec un serveur web qui traite plein de requêtes, et on m'a dit sur la liste de discussion OpenSSL que bah ouais, c'est à moi de me taper le boulot d'ajouter de l'entropie. Hasard détecte un fork et réinjecte lui-même de l'entropie.

Voir le dossier doc/ pour diverses notes sur les générateurs de nombres aléatoires et python/ pour les outils.

Vieux articles que j'avais écrit.

http://www.haypocalc.com/blog/index.php/2007/12/02/97-generateurs-nombres-pseudo-aleatoires
http://www.haypocalc.com/blog/index.php/2007/12/02/96-bugs-generateurs-de-nombres-pseudo-aleatoires
http://www.haypocalc.com/blog/index.php/2008/08/18/159-attaquer-un-gnrateur-de-nombres-pseudo-alatoires
http://www.haypocalc.com/blog/index.php/2008/06/09/149-developpement-bibliotheque-hasard

Voili voulou, bonne lecture.

PS : Il faudrait que je pense à faire une release d'ailleurs…

L'optimisation en occupation mémoire des chaînes de caractères n'a-t-elle pas un impact en performance cpu?

Côté positif : certaines opérations sont beaucoup plus rapide, notamment quand on manipule des chaînes de caractère "ASCII" :
http://docs.python.org/dev/whatsnew/3.3.html#optimizations

En gros : copier N caractères ASCII (stockés dans le format "UCS-1") nécessite de copier N octets, alors que copier N caractères stockés dans le format UCS-4 (Python 3.2 sous Linux) nécessite de copier 4*N octets. Par exemple, str[a:b] copie des caractères. Et comme l'a écrit Antoine : encoder une chaîne Unicode "de type ASCII" en UTF-8 revient simplement à faire un "memcpy" (en gros), ce qui est ultra rapide (comparé à l'encodeur de Python 2.7 et 3.2).

Côté négatif : les opérations manipulant des chaînes utilisant différents formats nécessitent de convertir les chaînes vers le même format. Par exemple, "10€".replace("", " ") nécessite de convertir "_" du format UCS-1 au format UCS-2. Idem pour "10 " + "€".

Créer une chaîne de caractère nécessite de connaître le caractère "maximum" (code Unicode le plus grand), ce qui nécessite de lire l'ensemble des caractères de la chaîne. Cette opération est coûteuse.

Le bilan est mitigé car certaines opérations sont plus lentes, mais d'un autre, certaines fonctions ont été optimisées. Dans le meilleur des cas, certaines opérations Unicode avec Python 3.3 sont désormais plus rapides que ces opérations sur des octets avec Python 2.7 !

Je ne connais pas de benchmark "global". Il existe divers micro-benchmarks qui ne sont pas représentatifs. En tout cas, il est sûr que la consommation mémoire est bien meilleure !

Voir aussi le journal d'Antoine annonçant la release candidate 2 :
https://linuxfr.org/users/pitrou/journaux/python-3-3-0-release-candidate-2
(notamment pour voir les commentaires)

Des concurrents de Twitter.

Le modèle "commercial" de LWN est de faire payer le contenu pendant une semaine après sa parution. Ici j'ai créé un "Suscriber Link" qui est une fonctionnalité très sympa permettant de donner l'accès à un article même aux non-abonnés.

Hum, ça me semble pas très sympa de crée un "Subscriber Link". Il suffirait d'attendre une semaine pour écrire ton journal, ou bien d'inviter à les lecteurs à s'abonner.

Bon, je m'en fous un peu, je paie mon abonnement avec mes propres deniers ;-)

Un thread ça va, c'est quand il y a en plusieurs qu'on a des problèmes.

Gérer plusieurs threads et plusieurs processus est très compliqué. Python est de plus en plus stable au fil du temps, à force que des utilisateurs remontent des crashs sur des cas tordus. Il y a par exemple régulièrement des bugs remontés sur l'erreur EINTR qui n'est pas bien gérée par le module subprocess : à force de corriger cette erreur, ça devrait être bon à la fin :-) Les interactions entre threads et signaux sont aussi gérés de manière plus fiable. Python 3.2 ajoute un module concurrent.futures qui abstrait un peu plus la programmation concurrentielle.

La programmation concurrentielle est également facilité par le support de timeout sur les verrous (ex: threading.Lock.acquire depuis Python 3.3) et les processus (ex: subprocess.Popen.communicate depuis Python 3.3).

Tu peux sûrement te contenter de Python 2.7, mais ça te coûtera plus cher en temps de développement, et surtout en débogage je pense. (pour retomber sur des bugs déjà corrigés dans Python 3 ?)

Je pense que Python 3 distance de plus en plus Python 2 en terme de performance. Python 3.3 utilise par exemple moins de mémoire que Python 2.7 pour un projet Django (dumoins pour les chaînes de caractère) :
http://www.python.org/dev/peps/pep-0393/#performance

C'est les PEP 393 (str) et 412 (dict) qui ont aidé pour ça. Les codecs texte ASCII, Latin1 et UTF-8 sont beaucoup plus rapides dans Python 3.3 que dans 2.7.

Python 3.2 a introduit un nouveau verrou global plus performant.

Optimisions de Python 3.3, 3.2 et 3.1.
http://docs.python.org/dev/whatsnew/3.3.html#optimizations
http://docs.python.org/dev/whatsnew/3.2.html#optimizations
http://docs.python.org/dev/whatsnew/3.1.html#optimizations

À force d'optimiser le code ça et là, ça devient beaucoup plus rapide d'une manière globale. Si en plus ça utilise moins de mémoire…

Morale de l'histoire:

• Amazon stocke vos numéros de carte banquaire (ça me choque vu le nombre d'affaires de vol de numéros de cartes bleu)
• Apple stocke les mots de passe en clair
• La sécurité d'un compte Google repose sur la sécurité de l'adresse mail de secours
• La sécurité d'un compte Twitter repose sur la sécurité de l'adresse mail associée
• Il y a une grosse faille de sécurité dans les services par téléphone d'Amazon qui permet de récupérer les 4 dernières chiffres des cartes banquaires utilisées par Amazon

Globalement, de nos jours, la sécurité de tous les services en ligne repose sur l'authentification de son compte mail.

Je vous conseille :

• Ne pas réutiliser le mot passe de votre compte mail sur d'autres services
• Si vous utilisez Goole : activer la double authentification, OTP via SMS (Google envoie un code de 6 chiffres quand on se connecte depuis un ordinateur inconnu)
• Cacher vos informations personnelles : adresse et téléphone par exemple
• De sauvegarder vos données, car mis à part les hacks, il y a aussi les pannes matérielles, les fausses manipulations ("rm -rf" du mauvais dossier, oups oups oups !), les catastrophes naturelles, le vol, données non récupérées quand on change d'ordinateur (ça m'arrive tous les 3 ans), etc. L'idéal étant d'avoir différents types de sauvegarde : serveurs quelque part sur l'internet, disques durs externes, DVD, etc. Et de les contrôler de temps à autre (avant LA catastrophe).

Réfléchissez-y à deux fois avant d'utiliser des services sur le cloud

Mouais, ça me semble être un raccourci un peu rapide quand même.

Au cours de mes pérégrination pythranesques, j'ai découvert une fleur du langage python, que je m'empresse de partager.

Ce n'est pas vraiment une "fonctionnalitée" cachée. Il y a d'autres manières d'avoir des variables locales pour une fonction.

Exemple avec une fermeture (closure) :

>>> def with_locals():
...  accu = []
...  def func():
...   accu.append(1)
...   print(accu)
...  return func
... 
>>> func = with_locals()
>>> func()
[1]
>>> func()
[1, 1]
>>> func()
[1, 1, 1]
>>> func()
[1, 1, 1, 1]

À partir de Python 3, on peut également modifier la variable (et non pas juste son contenu) grâce à nonlocal :

>>> def with_locals():
...  x = 0
...  def func():
...   nonlocal x
...   x += 1
...   print(x)
...  return func
... 
>>> func = with_locals()
>>> func()
1
>>> func()
2
>>> func()
3

On peut également utiliser des attributs arbitraires à la fonction pour y stocker des trucs :

>>> def hello():
...  print(hello.world)
... 
>>> hello.world="Hello World!"
>>> hello()
Hello World!
>>> hello.world="Bonjour Monde !"
>>> hello()
Bonjour Monde !

(La fonction peut également modifier hello.world)

Bon, y'a plus qu'à optimiser pythran pour qu'il fasse tourner Django plus vite que CPython, voir que PyPy ;-)

Je maintiens que c'est suffisant pour duper un utilisateur distrait (qui vérifie le début et la fin, alors que la fin c'est l'id). En tout cas ça suffit je pense pour éduquer les utilisateurs.

4096R/7C485DC1: E6…C1
4096R/7C485DC1: E9…C1

Mouais, faut vraiment lire que le première caractère ou bien être très distrait :-) Maintenant s'il n'y a que la fin qui est affichée, ça peut très bien fonctionner.

Sur #python-dev, on m'a parlé de cette conférence à EuroPython 2012 :
https://ep2012.europython.eu/conference/talks/nuitka-the-python-compiler

Et hop, un autre compilateur Python => C++, mais qui gère les classes et tout le bazar.

Je suis abonné à Free depuis plusieurs années. Avant j'avais une option IPv6 (activée), mais depuis mon dernier déménagement, je ne trouve plus l'option IPv6. J'ai un abonnement de type "Freebox Only NDI". Est-ce normal de ne pas avoir l'option ?

J'ai une Freebox v5, je me suis dit que c'est peut-être à cause de ça, sauf que je ne vois pas non plus comment demander à migrer vers une Freebox v6.

Ok, il s'agit donc d'un soucis de documentation : "salt" n'est pas mentionné dans
https://docs.djangoproject.com/en/dev/topics/auth/#auth-password-storage

On dirait que les mots de passe Django n'ont pas de sel. Or c'est une protection critique pour un site web où le risque de fuite est important. Ne pas utiliser de sel est une erreur courante, mais pourtant connue depuis de nombreuses années.

Extract d'une page OWASP: "Credentials MUST be stored after being one-way hashed and salted using acceptable hashing algorithms".

https://www.owasp.org/index.php/Guide_to_Authentication#Architectural_Goals

Passer de SHA1 à PBKDF2 me semble moins utile qu'ajouter du sel. (Les deux émaliorations n'étant pas exclusives.)

Projet similaire qui pourrait vous intéressé, je n'ai pas testé.

Python Data Analysis Library — pandas: Python Data Analysis Library
http://pandas.pydata.org/