08:30 <cyp:#afpy> plop
09:15 <morgan`:#afpy> hello
09:17 <feth:#afpy> bonjour
09:26 <solevis:#afpy> matin
11:32 <Maddingue:#afpy> halo
11:32 <Maddingue:#afpy> il n'y a pas une option de python(1) pour faire une vérification de compilation d'un programme/module ? (comme perl -c)
11:35 <haypo:#afpy> Maddingue: vérifie la syntaxe d'un fichier .py ?
11:35 <haypo:#afpy> vérifier*
11:36 <Maddingue:#afpy> oui
11:36 <Maddingue:#afpy> j'ai un programme en Python, je voudrais juste voir s'il est correct, sans 'exécuter
11:36 <haypo:#afpy> pas d'option pour le programme python. tu peux par exemple utiliser imp.load_source('bla', 'fichier.py')
11:36 <Maddingue:#afpy> arf
11:36 <haypo:#afpy> pas sûr que ça ne l'exécute pas
11:37 <Maddingue:#afpy> pas très pratique
11:37 <sbz:#afpy> Maddingue: python -mcompileall file.py
11:38 <Maddingue:#afpy> hmm, il ne prend pas un chemin vers un programme ?
11:38 <sbz:#afpy> Maddingue: ca te genere le bytecode et par exemple trouve les erreurs de syntaxe ect..
11:38 <Maddingue:#afpy> en plus, j'avais déjà trouvé comment faire il y a quelques mois... foutue mémoire..
11:39 <sbz:#afpy> Maddingue: en fait le -m c'est l'equivalent du -M perl, il charge le module compileall
11:39 <Maddingue:#afpy> sbz: oui, ça je m'en souviens
11:39 <Maddingue:#afpy> mais là il me sort "Can't list xxx"
11:39 <sbz:#afpy> Maddingue: il peut le faire sur tout un dossier/fichier mais je sais pour un programme, je l'utilise souvent comme ca
11:42 <sbz:#afpy> Maddingue: par exemple http://pastebin.com/W5JXiq61
11:42 <haypo:#afpy> Maddingue: dans Python 2, compileall utilise py_compile qui utilise exec
11:42 <haypo:#afpy> Maddingue: finalement, ça revient à faire qq. chose du genre python -c "import imp; compile(open('bla.py').read(), 'bla.py', 'exec')"
11:43 <haypo:#afpy> compile() n'exécute pas le code, contrairement à imp.load_source() :-)
11:43 <haypo:#afpy> sbz, Maddingue : salut au passage :)
11:43 <sbz:#afpy> haypo: Maddingue : salut :-)
11:43 <haypo:#afpy> sbz: alors, ça pythone bien ?
11:44 <sbz:#afpy> haypo: toujours :))
11:44 <haypo:#afpy> sbz: t'as eu des retours de ta bibliothèque SSH ?
11:44 <haypo:#afpy> sbz: elle est Python3 ready? /o\
11:45 <Maddingue:#afpy> j'ai l'impression que compileall ne marche qu'avec des fichiers .py
11:45 <haypo:#afpy> Maddingue: pourquoi, tu as quoi comme fichier toi ? des .exe ? :)
11:45 <sbz:#afpy> haypo: ouaip quelqu'un et justement faut que j'ajoute le support Python3 :(
11:45 <haypo:#afpy> sbz: rappelle moi l'url du projet stp
11:45 <haypo:#afpy> si ton projet est hébergé sur PyPI et qu'il est compatible Python3, il a le droit à une image spéciale
11:45 <sbz:#afpy> haypo: http://pypi.python.org/pypi/pylibssh2/
11:45 <haypo:#afpy> comme la tortue Kame qui bouge si t'es en IPv6 :-)
11:46 <Maddingue:#afpy> haypo: juste un nom de fichier, dans mon cas usr/sbin/xenballoond
11:46 <haypo:#afpy> sbz: peuh. regarde moi cette superbe image Python 3 super moderne http://pypi.python.org/pypi/faulthandler !
11:46 <haypo:#afpy> Maddingue: ça devrait aller avec compile
11:46 <haypo:#afpy> Maddingue: vu que dans mon exemple, je passe le contenu du fichier, et non pas un nom de fichier
11:47 <haypo:#afpy> Maddingue: (le 2e argument de compile est juste informatif, tu peux mettre ce que tu veux à mon avis)
11:47 <sbz:#afpy> haypo: j'ai vu que l'API des bindings a completement change en py3k et j'ai pas vraiment envie d'autogenerer le truc avec 2to3, donc va falloir que je m'adapte bientot
11:47 <haypo:#afpy> sbz: il existe 2to3c
11:47 <haypo:#afpy> sbz: faulthandler est entièrement écrit en C, et est compatible Python 2 et 3
11:47 <haypo:#afpy> sbz: j'ai mis des #ifdef dedans
11:48 <haypo:#afpy> finalement, je trouve qu'il y a peu de modifs à faire pour avoir du code C compatible Python 3
11:48 <sbz:#afpy> cool je vais m'en insiprer, merci et je connaissais pas segfaulthandler :P
11:49 <sbz:#afpy> haypo: le truc c'est qu'il faut assurer la retromcompatibilite aussi
11:49 <haypo:#afpy> sbz: faulthandler, y'a 2 ans ça ne gérait que SIGSEGV, aujourd'hui ça gère bien plus -:)
11:57 <Maddingue:#afpy> bon, python -c "import imp, sys; path=sys.argv[1]; compile(open(path).read(), path, 'exec')" semble fonctionne à peu près comme je m'y attends
12:06 <haypo:#afpy> Maddingue: tu vois, c'est super facile Python !
12:06 <Maddingue:#afpy> derp
12:06 <haypo:#afpy> perso je trouve Python trop laxiste par défaut
12:07 <haypo:#afpy> si tu veux une vérification plus stricte, il y a les options -Wd -Werror -bb -3
12:07 <haypo:#afpy> (options pour Python 3.2, je ne sais pas si elles s'utilisent tel quel avec Python 2.6 ou 2.7)
12:08 <haypo:#afpy> Maddingue: Python 2.4 ? ouh là
12:08 <haypo:#afpy> Maddingue: il serait temps de màj ta Sarge
12:09 <sbz:#afpy> et vu les nouveaux decorateurs dans unittest depuis 2.7 je crois qu'il va falloir que je change...
12:12 <haypo:#afpy> sbz: @skipIf ?
12:32 <sbz:#afpy> haypo: yep
12:37 <haypo:#afpy> sbz: j'ai réimplementé ce décorateur pour python < 3.2 : https://github.com/haypo/faulthandler/blob/master/tests.py#L14 (c'est aussi dispo pour python 2.7 ? je ne sais pas)
12:37 <haypo:#afpy> sbz: le print n'est pas très propre, mais au moins ça marche :)
12:37 <gawel:#afpy> unittest2
12:38 <sbz:#afpy> c'est un fou ce haypo :-)
12:38 <sbz:#afpy> salut gawel
12:38 <gawel:#afpy> http://pypi.python.org/pypi/unittest2
12:38 <gawel:#afpy> salut
12:47 <haypo:#afpy> sbz: pourquoi trouves-tu ça fou de réimplémenter un décorateur ?
12:47 <haypo:#afpy> gawel: ah ok, donc unittest existe aussi dans python 2.7
12:48 <haypo:#afpy> sbz: je préférai réimplementer le décorateur que de m'en passer. je ne connaissais pas http://pypi.python.org/pypi/unittest2 (même si j'avais entendu parler de ce backport)
12:53 <sbz:#afpy> haypo: le fou c'etait surtout sur le nombre de projet que tu geres
12:53 <haypo:#afpy> sbz: boarf, j'abandonne les projets petit à petit :)
13:01 <sbz:#afpy> haypo: et moi j'en commence et en rejoins :-)
13:05 <haypo:#afpy> bah maintenant je bosse surtout sur Python, c'est plus constructif que le NIH :)
13:13 <sbz:#afpy> hehe tu mets le boxon dans le svn python :P
13:19 <haypo:#afpy> sbz: pas du tout
13:23 <sbz:#afpy> c'etait ironique :):
14:24 <Maddingue:#afpy> haypo: etch aussi a python 2.4
15:00 <haypo:#afpy> Maddingue: etch !
15:00 <haypo:#afpy> Maddingue: il est tellement bien ton boulot ? :)
15:18 <sbz:#afpy> Maddingue: et toutes les failles de secu sont a jours ? :)
15:22 <Maddingue:#afpy> vous n'avez peut-être pas encore rencontré le terme de "production" dans votre carrière..
15:25 <Maddingue:#afpy> bon, je ne sais pas si c'est lié à ma version 2.4 ou à autre chose, mais le mode uniligne est inutilisable, j'ai des comportements sont aberrants
15:25 <Maddingue:#afpy> *qui
15:35 <haypo:#afpy> Maddingue: c'est pas possible de mettre à jour les applications sur ce vieux serveur ?
15:35 <haypo:#afpy> pour moi, un serveur utilisant Etch est un serveur mort :)
15:36 <Maddingue:#afpy> haypo: chez nous, c'est de la production. qui rapporte de l'argent.
15:37 <haypo:#afpy> Maddingue: et ça coûte pas trop en maintenance un serveur Etch ?
15:41 <yotaff:#afpy> j'ai encore un produit qui se base sur sarge
15:41 <yotaff:#afpy> qui va etre remplacer officiellement dans 2 mois
15:41 <Maddingue:#afpy> en quoi ça couterait plus qu'une distro actuelle ?
15:42 <Maddingue:#afpy> on est en phase de migration vers Ubuntu, mais on n'upgrade pas 3000 machines réparties sur 3 sites en un claquement de doigts
15:42 <haypo:#afpy> Maddingue: c'est plus pénible d'écrire du code python 2.4 que 2.7
15:42 <Maddingue:#afpy> ah mais il n'y a pas de Python en prod chez nous
15:43 <yotaff:#afpy> Maddingue: ubuntu ?
15:43 <Maddingue:#afpy> (enfin, si, il y a quelques bouts ici et là, mais pas du très sophistiqué à ce qu'on m'a dit)
15:43 <yotaff:#afpy> perso, j'ai testé un peu y'a 1 an et j'ai toujours pas confiance
15:44 <haypo:#afpy> Maddingue: ah, tu disais "etch aussi a python 2.4", je pensais que tu disais ça parce que tu administrais des serveurs utilisant des applications écrites pour Python 2.4
15:44 <haypo:#afpy> hier j'ai mis à jour ma Ubuntu 10.04 => pif paf, freeze noyau
15:44 <Maddingue:#afpy> il y a des resistances, mais le choix s'est porté sur Ubuntu de par le fait que c'est du Debian++, donc c'est "plus simple", "moins risqué" que de migrer vers CentOS ou Gentoo par exemple
15:44 <haypo:#afpy> alors que je met souvent à jour ma Debian Sid => jamais aucun soucis, ou alors sûrement pas aussi graves
15:45 <haypo:#afpy> Maddingue: c'est des postes de travail ou des serveurs ?
15:45 <Maddingue:#afpy> il y a eu aussi une bonne campagne de certaines personnes en faveur d'Ubuntu
15:45 <Maddingue:#afpy> haypo: j'ai parlé de production, donc de serveurs :)
15:46 <harobed:#afpy> Maddingue, tu gères 3000 machines !
15:48 <Maddingue:#afpy> non, pas moi
15:48 <Maddingue:#afpy> mais je maintiens un logiciel qui est déployé sur toutes ces machines
15:49 <harobed:#afpy> et bien, ça fait pas mal
15:51 <Maddingue:#afpy> pour rappel, je suis un sysadmin, et normalement je fais du Perl, mais là je regarde un programme (xenballoond) écrit par des collègues qui permet de faire de l'allocation dynamique de mémoire à des VMs Xen
15:52 <Maddingue:#afpy> ce programme est écrit en Python, d'où mes questions précédentes
15:52 <Maddingue:#afpy> je voulais voir s'il y avait des choses à améliorer, et je pense en avoir trouvé
15:52 <tarek:#afpy> mike_perdide, ping
15:53 <haypo:#afpy> Maddingue: les postes de travail ne servent pas à produire ? :)
15:53 <Maddingue:#afpy> haypo: on nous migre sous Windows XP (oui tu as bien lu, XP). tu as le droit de rigoler
15:54 <haypo:#afpy> bah c'est le meilleur des Windows, XP
15:54 <Maddingue:#afpy> [xenballoond] en particulier, il y a des tas d'exécution de commandes externes, par exemple : subprocess.call("%s memory/uptime \"%s\"" % (xs_write, uptime), shell=True)
15:54 <Maddingue:#afpy> ce qui peut se récrire, sauf erreur de ma part, de manière plus optimale : subprocess.call([xs_write, "memory/uptime", uptime])
15:55 <haypo:#afpy> Maddingue: ça évite le processus intermédiaire du shell oui
15:55 <haypo:#afpy> il me semble aussi qui c'est équivalent, mais j'ai toujours du mal avec shell=True
15:56 <Maddingue:#afpy> d'une part le shell intermédiaire, très couteux, mais aussi le sprintf, iuntile et peu lisible
15:58 <haypo:#afpy> shell=True a un avantage, ça permet d'exécuter des commandes shell arbitraires !
15:58 <Maddingue:#afpy> des commandes internes au shell tu veux dire ?
15:58 <Maddingue:#afpy> en effet, mais là on execute seulement des programmes externes
16:00 <haypo:#afpy> Maddingue: des trucs du genre "; rm -rf / #
16:00 <No`:#afpy> bonjour l'afpy
16:02 <Maddingue:#afpy> oui, c'est aussi utile en terme de sécurité
16:03 <Maddingue:#afpy> mais bon, là, dans ce programme, il va falloir commencer bien avant parce qu'ils font un truc bien crade
16:04 <Maddingue:#afpy> un execfile() du fichier de config, ce qui permet ensuite de faire des if sur les variables définies dans le fichier..
16:40 <david`bgk:#afpy> http://apluggedinlife.com/media/photos/from_PHP_to_Python/1.jpg
16:40 <david`bgk:#afpy> qui est-ce qui rédige l'article php/python déjà ? :)
16:41 <No`:#afpy> t'ain l'autre il appelle son Django Poney "Jolly Jumper"
16:52 <sbz:#afpy> Maddingue: pwarf XP c'est a cause du e-buro ?
16:52 <Maddingue:#afpy> sbz: oui
16:53 <sbz:#afpy> Maddingue: bon courage, ca m'a l'air super *relou*
16:59 <Maddingue:#afpy> pour le moment, je resiste, j'ai encore mon poste Linux
17:01 <Maddingue:#afpy> dernière question de la journée : il y a moyen de rendre execve moins coincé du cul ou de transtyper plus simplement qu'avec des "%s"%.. sur tous les arguments qu'il refuse de trivialement convertir en chaine ?
17:05 <ogrisel:#afpy> haypo: t'es en train de dire que les "shell injections" sont une feature et pas un bug c'est ca ?
17:07 <misc:#afpy> oui, faut plus dire "exploit à distance", mais "administration flexible à travers le réseau"
17:09 <haypo:#afpy> ogrisel: bien sûr
17:09 <Maddingue:#afpy> misc: un peu plus de buzzwords ontologiques pour augmenter la valeur paradigmatique intrinsèque des assets, et ce sera bankable
17:09 <haypo:#afpy> d'ailleurs, les développeurs PHP se sont données du mal pour réimplémenter la même chose en SQL !
17:09 <Maddingue:#afpy> le pire en PHP, c'est qu'on peut passer du code PHP dans open()
17:10 <ogrisel:#afpy> Maddingue: c'est toi la valeur paradigmatique
17:11 <haypo:#afpy> Maddingue: en Perl, y'a mieux : open("|commande shell")
17:12 <Maddingue:#afpy> haypo: certes, mais tu peux désactiver complètement ce mécanisme avec open my $fh, "<", $path
17:12 <ogrisel:#afpy> ce qui parait intuitif et lisible :)
17:13 <Maddingue:#afpy> c'est la manière classique. on peut écrire ça plus court en objet
17:13 <sbz:#afpy> petite confirmation ? dans le cas d'une re-adhesion j'ai besoin d'envoyer un courrier ou pas ? je crois pas mais histoire d'etre sur...
17:14 <Maddingue:#afpy> en attendant, vous n'avez pas répondu à ma question sur le transtypage. ya pas moins "bruit de ligne" que des "%s"%.. ?
17:15 <haypo:#afpy> Maddingue: str(bla) ?
17:16 <Maddingue:#afpy> ok, mieux. mais donc je reste obligé de tout transtyper ?
17:18 <haypo:#afpy> Maddingue: que ce qui n'est pas une chaîne
17:19 <Maddingue:#afpy> meh
17:24 <haypo:#afpy> Maddingue: explicit is better than implicit dit le dicton Python
17:27 <haypo:#afpy> david`bgk: j'aime beaucoup le dessin avec le poney Django :)
17:27 <Maddingue:#afpy> mouais mais bon. je parie que vous n'avez pas à faire ce genre de transtypage pour faire une page web
17:27 <haypo:#afpy> Maddingue: tu lances souvent execve() dans une page web toi ?
17:29 <Maddingue:#afpy> ConfigParser, c'est toujours présent dans les python récents ?
17:30 <Maddingue:#afpy> a priori oui
17:31 <feth:#afpy> SafeConfigParser aussi
17:31 <haypo:#afpy> Maddingue: je crois qu'aucun module n'a été supprimé entre Python 2.0 et Python 2.7
17:32 <haypo:#afpy> Maddingue: (par contre, y'a plein de modules chelou qui ont disparu dans Python 3, genre les modules en 2 lettres pour IRIC : al, AL, fl, FL, flp, ...)
17:32 <Maddingue:#afpy> feth: quelle est la différence entre les deux ?
17:32 <haypo:#afpy> IRIX*
17:32 <haypo:#afpy> ConfigParser interprète %s dans le fichier de conf
17:33 <Maddingue:#afpy> si ce n'est que ça
17:33 <feth:#afpy> Maddingue: cela dit je préfère QSettings :)
17:34 <Maddingue:#afpy> ça ne semble pas dispo de base ni en 2.4, ni même en 2.6
17:34 <haypo:#afpy> Maddingue: hu ?
17:34 <haypo:#afpy> Maddingue: QSettings ou ConfigParser ?
17:35 <Maddingue:#afpy> QSettings
17:35 <feth:#afpy> Maddingue: comme le Q au début du nom l'indique c'est du pyqt
17:35 <feth:#afpy> pardon pour la distraction
17:35 <feth:#afpy> tu n'en veux pas :)
17:35 <Maddingue:#afpy> feth: pas de souci, ce sera pour ma culture personnelle :)
17:36 <haypo:#afpy> feth: Q c'est plutôt Qt en général :)
17:36 <Maddingue:#afpy> mais ConfigParser semble bien. c'est pour remplacer ce dont je parlais tout à l'heure, et virer le execfile sur le fichier de configuration
17:36 <Maddingue:#afpy> parce que ça aussi c'est pas propre
17:37 <haypo:#afpy> tu pourrais être original et utiliser un fichier de config écrit en Perl
17:37 <gawel:#afpy> tu peux regarder ConfigObject sinon </pub>
17:38 <feth:#afpy> haypo: en lua, apparemment c'est la mode
17:39 <Maddingue:#afpy> haypo: roh, trolleur :p
17:57 <haypo:#afpy> feth: imapfilter est une config en Lua, j'ai un peu galére pour écrire mes règles
17:59 <feth:#afpy> haypo: c'est côté client ou côté serveur ?
17:59 <misc:#afpy> client
17:59 <feth:#afpy> ah, m'intéresse pas alors
17:59 <feth:#afpy> j'utilise dropmail côté serveur, ça ressemble un peu à du Python
18:00 <misc:#afpy> perso, j'ai utilisé imapfilter pendant longtemps, c'est sympa
18:00 <feth:#afpy> euh non, pardonnez ma sénilité
18:00 <misc:#afpy> maildrop
18:00 <feth:#afpy> misc: c'est ça :)
18:00 <feth:#afpy> mais ça ressemble pas à du python
18:01 <feth:#afpy> je confonds avec un truc qui a rien à voir
18:01 <haypo:#afpy> j'utilise getmail+maildrop pour récupérer en POP3, puis j'héberge mes mails en IMAP
18:01 <feth:#afpy> Sinon je trouve beaucoup plus rationnel d'avoir un filtre côté serveur
18:01 <No`:#afpy> ça ressemble à du python, ça a le goût du python...
18:01 <haypo:#afpy> mais imapfilter, c'est pour le serveur mail du boulot sur lequel je ne sais pas comment filtrer à la réception
18:01 <No`:#afpy> mais ce n'est pas du Python
18:01 <feth:#afpy> haypo: ah oui, faut savoir faire du sieve
18:02 <feth:#afpy> (j'ai jamais su)
18:06 <yotaff:#afpy> moi j'ai arreté de me prendre la tete la dessus
18:09 <haypo:#afpy> yotaff: et ça range "tout seul" ?
18:11 <feth:#afpy> Le mieux c'est plein de comptes mail -> un seul serveur imap, je trouve
18:17 <misc:#afpy> moi, j'ai un systéme ou je mets les mails dans un dossier, et j'ai un script perl qui va rajouter la regle qui va bien dans maildrop avant de commiter dans svn, via cron
18:18 <NelleV:#afpy> commit svn automatique \o/
18:21 <haypo:#afpy> misc: c'est quoi "la règle qui va bien" ?
18:23 <misc:#afpy> haypo: une heuristique
18:23 <misc:#afpy> je regarde si les mails ont un entete list-id, sinon je regarde si le from est le même
18:23 <misc:#afpy> ou ce genre de truc
18:23 <misc:#afpy> vu que je classe mes mails par ml, et par personne
18:57 <yotaff:#afpy> haypo: comprends pas la question
18:59 <feth:#afpy> yotaff: nous sommes abonnés à plein de listes. Et on reçoit du spam. Quand un mail arrive, nous le rangeons dans un dossier correspondant à des critères, genre "mailing list" ou "spam"
19:00 <feth:#afpy> enfin, on utilise des scripts pour ça
19:44 <haypo:#afpy> yotaff: on parlait de classer les mails par dossier. gmail se débrouille pour classer lui-même les mails comme tu le ferais manuellement ?
19:49 <gawel:#afpy> tu utilise des règles qui tag les mails et tu accède a des dossiers virtuel de ces tags, en gros
19:49 <gawel:#afpy> tu peux aussi tagger manuellement
20:05 <mike_perdide:#afpy> tarek: ping, je suis à dijon là
20:05 <tarek:#afpy> mike_perdide, on voit ton prof ?
20:05 <tarek:#afpy> vendredi ?
20:05 <mike_perdide:#afpy> pas de réponse de mon directeur des études, je l'ai relancé aujourd'hui
20:06 <tarek:#afpy> ah mm ok
20:06 <tarek:#afpy> tiens moi au courant
20:06 <mike_perdide:#afpy> dès que j'ai une réponse oui
20:09 <tarek:#afpy> ok
20:09 <tarek:#afpy> moi il me faut un peu de delai pour venir
20:09 <tarek:#afpy> genre la veille au mini
20:10 <mike_perdide:#afpy> tarek: j'ai malheureusement pas la pleine maîtrise du dossier
20:10 <mike_perdide:#afpy> je comprends pas trop son silence
20:10 <tarek:#afpy> oui
20:10 <tarek:#afpy> bah
20:11 <tarek:#afpy> on peut aussi appeler
20:11 <tarek:#afpy> ou debarquer
20:16 <mike_perdide:#afpy> tarek: il est un poil militaire sur les bords, je voudrais pas trop le brusquer
20:16 <mike_perdide:#afpy> nouveau mail envoyé
20:16 <tarek:#afpy> haha
20:16 <tarek:#afpy> je mettrais un treillis
20:16 <mike_perdide:#afpy> :)
20:16 <mike_perdide:#afpy> on le surnommait pistolet mitrailleur
20:16 <mike_perdide:#afpy> (initiales P.M.)
20:22 <tarek:#afpy> hehe
20:53 <feth:#afpy> les tags en imap, ça donne envoe d'abandonner le format Maildir, voire de déléguer sa vie privée à gmail
20:53 <feth:#afpy> c'est vrai