09:09 <morgan`:#afpy> bonjour
10:06 <kujiu:#afpy> bonjour
11:56 <No`:#afpy> salut l'afpy
12:03 <Solevis:#afpy> Bonjour
13:22 <ccomb:#afpy> gawel: faut trouver le moyen que tu me fasses un cheque pour la MAIF d'ici demain
13:22 <ccomb:#afpy> la limite est le 7
13:31 <benoitc:#afpy> qqn a un exemple de code hebergé avec hg pour gérer une branche pour python 3 ?
13:33 <gawel> ah putain :/
13:33 <gawel> ccomb: je te le file demain soir ?
13:37 <yotaff> benoitc: ?
13:38 <benoitc> je cherche à maintenir une version d'une lib pour py2.x et py3.1
13:38 <benoitc> so je cherche un bon process pour maintenir ça facilement
14:14 <haypo> benoitc: pourquoi tu veux faire une branche ?
14:15 <haypo> benoitc: le mieux est d'adapter le code python2 pour que la conversion 2to3 se passe bien
14:15 <haypo> perso je rajoute quelques tests sur la version de Python quand c'est pas possible de faire autrement
14:15 <haypo> comme ça je n'ai qu'une seule version de mon code
14:15 <haypo> et je convertis avec 2to3 au besoin
14:15 <haypo> d'ailleurs il me semble que distribute est capable de convertir automatiquement
14:15 <benoitc> hum
14:16 <benoitc> j'aime pas trop l'idée d'appliquer comme ça un patch
14:18 <haypo> un patch pour python3 ?
14:22 <benoitc> bah 2to3 génere un diff
14:25 <david`bgk> oui il me semblait que 2to3 n'y arrivait pas toujours
14:26 <benoitc> le diff là est ok
14:26 <benoitc> mais je préfère quand me^me avoir des unitests fonctionnels
14:27 <haypo> benoitc: tu peux demander à 2to3 de modifier les fichiers directement (mais il écrit quand même le diff en sortie, chose inutile mais bon)
14:27 <haypo> je vois pas le rapport avec tes tests unitaires
14:27 <haypo> après la conversion tes tests ne fonctionnent plus ?
14:27 <haypo> 2to3 sait aussi convertir les docstring et tests dans un fichier reST (.rst)
14:27 <benoitc> non j'ai des tests sur le unicode
14:27 <haypo> avec l'option -d
14:27 <benoitc> chaines u"blah"
14:27 <benoitc> par ex
14:28 <benoitc> il me crée une lolie error
14:28 <haypo> qu'est-ce qui déclanche une erreur ?
14:28 <haypo> 2to3 ?
14:28 <haypo> tes tests après conversion ?
14:29 <benoitc> yup
14:29 <haypo> euh j'ai pas compris
14:29 <benoitc> j'ai un self.assert_(body = u"éàù") dans mes tests
14:30 <benoitc> et il me sort une erreur qu'il faut que je relance
14:30 <haypo> après conversion tu as u"éàù" ?
14:30 <haypo> u"..." n'existe plus en python3, je comprend pas
14:31 <benoitc> non avant conversion j'ai ça dans mes tests
14:31 <benoitc> mmm je reessaies de rappliquer le diff
14:31 <haypo> l'erreur est provoquée par l'assertion ?
14:33 <benoitc> (couchdbkit)enlil:tests benoitc$ python3.1 httpc_test.py
14:33 <benoitc> File "httpc_test.py", line 109
14:33 <benoitc> self.assert_(result.unicode_body == u"éàù@")
14:33 <benoitc> mais je regarde en appliant le diff sur tt
14:34 <haypo> en python3, u"..." n'existe plus. tu devrais avoir une erreur de syntaxe
14:35 <benoitc> oui donc le test existe , pas de conversion appliqué dessus je regarde comment faire pour que 2to3 soit appliqué sur ts les fichiers
14:35 <haypo> tu peux donner explicitement une liste de fichiers à 2to3
14:35 <haypo> genre 2to3 -w $(find -name "*.py" -o -name "*.rst")
14:36 <haypo> j'utilise ça :
14:36 <haypo> 2to3 -w . fuzzers/fusil-* fuzzers/notworking/fusil-*
14:36 <haypo> 2to3 -w -d doc/*.rst tests/*.rst
14:36 <haypo> patch -p1 < python3.0.patch
14:36 <haypo> je spécifie explicitement fuzzers/fusil-* fuzzers/notworking/fusil-* parce que c'est des scripts python mais comme le nom de fichier ne se termine pas par ".py", 2to3 ne les détecte pas
14:36 <haypo> et oui, j'ai un patch en plus car pour les trucs que 2to3 ne sait pas adapter tout seul
14:37 <benoitc> mmm j'utilise pas de doctests là mais je peux adapter
14:37 <benoitc> merci
14:37 <haypo> (essentiellement des soucis avec les types bytes / str / unicode)
14:37 <benoitc> le plus important est de pouvoir distribuer via un setup.py qui va bien à la fin
14:37 <haypo> benoitc: ben il existe un moyen de convertir ton projet pour Python3 "à la volée" via setup.py
14:37 <haypo> mais j'ai jamais pratiqué, j'en sais pas plus
14:38 <benoitc> http://packages.python.org/distribute/python3.html#distributing-python-3-modules ?
14:39 <haypo> extra = {}
14:39 <haypo> if sys.version_info >= (3,): extra['use_2to3'] = True extra['convert_2to3_doctests'] = ['src/your/module/README.txt']
14:39 <haypo> ils ont pensé à tout :)
14:39 <haypo> (manque les retours à la ligne
14:39 <haypo> )
14:39 <benoitc> (pratique pour ceux qui ont des doctests
14:39 <benoitc> :)
14:40 <haypo> quoi ? t'as pas de doctest !!
14:41 <haypo> bouh la honte !
14:41 <misc> haypo: y a des doctests dans tout tes projets ?
14:41 <benoitc> non je ne vois pas pq je devrais me farci cette merde de ReST
14:41 <haypo> misc: yep
14:41 <haypo> misc: mais parfois sur une seule fonction avec un seul test :-)
14:42 <misc> haypo: y compris dans ton taf ?
14:42 <haypo> misc: yep
14:42 <misc> wow
14:42 <benoitc> j'ai des unitests pour tt mais pas de doctests
14:42 <haypo> on est pro ou on ne l'est pas
14:42 <benoitc> et si j'en avais je pense que je les mettrais avec le code tant qu'à faire
14:42 <haypo> je mélange le tests dans le code, dans des fichiers .rst à part, et parfois avec des tests py.test
14:43 <haypo> (voir des tests unittest pour mes anciens projets)
14:43 <benoitc> oui enfin au final on en arrive à utiliser des trucs comme sphinx
14:43 <benoitc> et là c'est la fin.
14:46 <benoitc> haypo: pq écrire des doctests plutot que des unitests anyway ?
14:47 <haypo> benoitc: pour s'en servir comme documentation
14:47 <haypo> les deux ne servent pas à la même chose
14:49 <kujiu> benoitc: tu reproches quoi à sphinx ?
14:51 <benoitc> qu'il soit basé sur rest, qu'il soit peu customisable mêm s'il utilise des templates et qu'au finalbcp de gens écrivent la doc en dehors du code
14:52 <No`> pourtant, autodoc, ça marche plutôt bien dans sphinx
14:52 <kujiu> oui, c'est l'impression que j'ai aussi No`
14:52 <benoitc> oui mais bcp de gens ne l'utilise pas forcememnt
14:52 <kujiu> j'utilise pas parce que j'ai du code python 2.3 à gérer
14:52 <No`> et un répertoire "doc" dans le projet, j'aime autant que de devoir piocher dans du code
14:53 <benoitc> et puis bon tt ce code pour génerer ça
14:53 <kujiu> et rest ça permet une mise en forme, c'est plutôt sympa
14:53 <No`> y'a des fois, les fonctions magiques, c'est difficile à trouver dans le code
14:53 <benoitc> anyway c'ests urtout que ça utilise ReST
14:53 <No`> heh
14:54 <No`> benoitc et ses goûts/dégoûts... c'est pour ça qu'on l'aime
14:54 <benoitc> ahah
14:55 <benoitc> Si sphinx me permet de générer un site aussi simplement que mon script ok mais en attendnat ça reste difficile pour generer des trucs comme http://couchdbkit.org/
14:56 <No`> chaque outil a son utilisation
14:57 <No`> honnêtement, la doc de l'API de couchdbkit, je trouve ça assez aride
14:58 <benoitc> oui je prefereais avoir un truc comme http://erldocs.com/R13B03
14:58 <kujiu> j'ai du mal aussi avec cette doc
14:58 <kujiu> ça c'est un peu mieux
14:59 <haypo> je trouve http://erldocs.com/R13B03 plus laid que http://docs.python.org/
14:59 <haypo> mais moins pire que de la doc Java :)
15:00 <benoitc> docs.python.org est completement écris à part
15:00 <benoitc> rien à voir avce un acces api
15:00 <No`> mais la mochitude, c'est une chose. la lisibilité, c'en est une autre
15:00 <haypo> benoitc: bah si, ça documente plein de modules
15:01 <haypo> http://docs.python.org/library/abc.html c'est une API par exemple, http://docs.python.org/library/threading.html aussi : et c'est joli :)
15:01 <benoitc> c'est écrits à part
15:01 <haypo> benoitc: qu'est-ce que tu veux dire par "à part" ?
15:01 <benoitc> ce n'est pas écrits dans le code
15:01 <haypo> ah oui, bah c'est mieux :)
15:01 <haypo> ça donne un document plus lisible
15:02 <benoitc> plus lisible ?
15:02 <haypo> les documents qui listent toutes les classes, méthodes, attributs, propriétés, constantes, etc. je trouve ça imbitable
15:02 <benoitc> mok
15:02 <haypo> (incompréhensible, inutile)
15:02 <haypo> autant lire le code source quoi )
15:02 <haypo> :)
15:03 <benoitc> on doit pas avoir la même façon de chercher une notion de code alors
15:04 <benoitc> mais bon la doc de python est tres bien ceci dit écrites à part et demande bcp de taf
15:05 <No`> s/de python est tres bien ceci dit écrite à part et//
15:05 <benoitc> et je suis fan du literrate programming
15:06 <benoitc> + cela demande du monde
15:07 <haypo> No`: oui, documenter un projet prend du temps :)
15:07 <kujiu> benoitc: oui mais bon, une bonne doc est forcément écrite à part
15:07 <benoitc> kujiu: je ne vois pas en quoi c'est meilleure que de génerer une api
15:08 <benoitc> -e
15:08 <haypo> bah pour moi y'a 2 types de doc : doc. développeur (API exhaustive) et doc. utilisateur (explique pas à pas comment se servir des classes)
15:08 <kujiu> ben avec l'api tu génères un gros trucs complètement documenté
15:08 <kujiu> y compris les attributs privé
15:08 <kujiu> s
15:08 <kujiu> si tu veux que ta doc explique le fonctionnement d'une librairie
15:08 <haypo> la doc. développeur se génère à partir du code source et je n'en ai lu aucune qui était plus utile que de lire le code source directement
15:08 <kujiu> tu t'abstiens de donner les hacks possibles
15:09 <kujiu> haypo: et en plus ça impose un code clair ça
15:09 <kujiu> que des avantages :)
15:09 <No`> et la doc utilisateur te donne un exemple d'utilisation, aussi
15:09 <kujiu> voilà
15:10 <benoitc> oui donc on parlait dela partie api
15:10 <benoitc> tu peux generer d'autres pages pour expliquer le fonctionnement global
15:10 <haypo> bah la grosse différence autre les deux docs est que l'une est exhaustive (longue) et l'autre ne parle que des trucs utiles 90% du temps (concis)
15:10 <benoitc> mais derriere le nerf de la guerre c'estla réference
15:10 <No`> au lieu de réinventer une méthode qui existe déjà, tu utilises celle qui est dans la doc utilisateur
15:11 <benoitc> moui
15:11 <No`> c'est chiant de se rendre compte que ta super-fonction que tu as créé elle existait déjà, mais qu'il y avait tellement de références dans la doc que tu l'as pas vue
15:11 <No`> ça m'est arrivé
15:11 <haypo> No`: pour comprendre en 30 secondes comment marche un truc, un exemple de 5 lignes est plus utile que 5 Km de documentation. c'est sûr
15:11 <No`> c'est frustrant
15:11 <haypo> je suis très critique vis à vis de la doc, mais j'en ai écrit (presque) jamais :)
15:12 <No`> hah
15:12 <benoitc> c'est surtout une quetsion d'objectif
15:12 <benoitc> soit tu crées une lib pour une lib
15:12 <benoitc> soit tu crées uen lib pour ton usage et que tu mets à dispos
15:12 <No`> dès que le projet prend un peu d'ampleur, ça peut faire du bien de rédiger à part un vrai tuto, une doc un peu plus "littéraire"
15:12 <No`> même pour soi
15:13 <kujiu> et franchement quitte à générer une doc d'une API autant prendre des outils comme doxygen qui va générer des graphes...
15:13 <No`> pour quand tu reviens sur ton propre code 6 mois plus tard
15:13 <No`> et qu'Alzheimer est passé par là
15:13 <benoitc> bah il y a les unitests pour ça
15:13 <kujiu> mais sinon, je suis pour la doc littéraire aussi
15:14 <benoitc> mmm à ce rhythme là tu ne fais pas grand chose de ton code
15:16 <benoitc> No`: anyway oui il est prévu d'augmenter les usesdocs de couchdbkit , mais ça va attendre que je release la version desktop :)
15:16 <benoitc> et puis je suis preneur de tt patch ;)
15:48 <benoitc> No`: pm
16:07 <benoitc> haypo: btw déjà testé cucumber vs les doctests & co ?
16:10 <haypo> benoitc: je ne connais pas cucumber
16:10 <benoitc> k
16:11 <benoitc> http://wiki.github.com/aslakhellesoy/cucumber