08:23 <cyp:#afpy> plop
10:33 <haypo:#afpy> ccomb: salut. le bug dont tu m'as parlé dans le bar l'autre soir, je l'avais déjà corrigé :-)
10:33 <haypo:#afpy> ccomb: python 3.1.2 n'a plus ce bug
10:33 <haypo:#afpy> (je me souvenais plus que je l'avais corrigé)
10:34 <haypo:#afpy> en tout cas, twitter n'est pas le bon endroit pour rapporter des bugs (mais tu as fini par ouvrir un ticket ;-))
10:34 <ccomb:#afpy> haypo: hello
10:34 <ccomb:#afpy> oui j'ai vu :)
10:34 <ccomb:#afpy> si qqu'un m'avait twitté une réponse en disant que c'était corrigé, j'aurai pas eu besoin de rapporter le bug
10:35 <ccomb:#afpy> mais apparemment j'ai voulu faire des trucs tordu
10:35 <ccomb:#afpy> mais je me demande encore comment récupérer un bytes au lieu d'un string pour sys.argv
10:35 <haypo:#afpy> ccomb: je pense qu'il faudrait supprimer sys.setfilesystemencoding()
10:35 <ccomb:#afpy> si tu lui met un truc encodé n'importe comment il peut pas le convertir
10:36 <haypo:#afpy> "comment récupérer un bytes au lieu d'un string pour sys.argv" : il faut le faire manuellement ça par contre :-/
10:36 <haypo:#afpy> encoding = sys.getfilesystemencoding(); argv_bytes = [arg.encode(encoding, "surrogateescape") for arg in sys.argv]
10:36 <haypo:#afpy> j'ai introduit os.environb récemment dans python 3.2 pour récupérer les variables d'environnement sous forme de bytes
10:37 <haypo:#afpy> ccomb: jette aussi un oeil à http://www.haypocalc.com/wiki/Python_Unicode#En_pratique_avec_Python3
10:37 <ccomb:#afpy> alors là ces trucs de surrogate, j'y comprends rien
10:37 <ccomb:#afpy> en python 2 on avait des unicodeencodeerror, en python 3 on va avoir des surrogate errors :D ?
10:37 <haypo:#afpy> ccomb: t'es pas le seul :-) c'est la PEP 383
10:38 <haypo:#afpy> ccomb: les surrogates sont une solution pour ne plus avoir de UnicodeDecodeError
10:38 <haypo:#afpy> s'il y a une séquence d'octets invalides (dans le jeu de caractères utilisé), elle est stockée sous forme de surrogates : dans une plage Unicode spéciale (U+DC00..U+DCFF)
10:38 <ccomb:#afpy> ok mais alors autant on peut arriver à comprendre une unicodeencodeerror, autant quand on a une surrogate error c'est effrayant
10:39 <ccomb:#afpy> ah ok
10:39 <haypo:#afpy> ex: b'\xFF' est stocké sous forme de U+DCFF
10:39 <haypo:#afpy> ah si, il existe des "surrogates error" : encoder une chaîne qui contient des surrogates en utf8 génère une telle erreur
10:40 <haypo:#afpy> on a toujours le problème, mais plus tad :-)
10:40 <haypo:#afpy> tard*
10:40 <ccomb:#afpy> en tout cas y a qques merdes comme ça, mais il y a de plus en plus de trucs qui me donnent envie de faire du python 3
10:40 <haypo:#afpy> ccomb: faut que j'écrive un tutoriel sur le support d'unicode dans python3 car ça semble effrayer pas mal de monde :-)
10:40 <flox:#afpy> manque plus qu'une spec WSGI décente pour python 3 ;)
10:41 <flox:#afpy> il y en a qui y travaillent
10:41 <ccomb:#afpy> décente ca veut dire quoi, WSGI 2 ?
10:41 <haypo:#afpy> ccomb: en général, tu n'as pas à utiliser surrogateescape explicitement
10:41 <ccomb:#afpy> ou une implémentation efficace de wsgiref?*
10:41 <haypo:#afpy> ccomb: ex: os.listdir() te créer des noms de fichier avec surrogates. tu les passes à open() : open() fait ce qu'il faut pour ouvrir le fichier
10:41 <haypo:#afpy> "juste ça marche"
10:42 <flox:#afpy> ccomb: a priori la norme wsgi 1.0 n'est pas compatible Python 3
10:42 <flox:#afpy> il y a des efforts sur la ml web-sig pour préparer un amendement wsgi 1.1
10:42 <ccomb:#afpy> ah c'est dommage ça
10:43 <ccomb:#afpy> et l'équivalent d'un virtualenv dans python, c'est démarré ?
10:44 <haypo:#afpy> ccomb: j'ai pas entendu que virtualenv entrerait dans python
10:44 <ccomb:#afpy> pas virtualenv, mais un truc qui fait en gros la meme chose
10:44 <ccomb:#afpy> j'avais entendu ça
10:44 <ccomb:#afpy> ce serait génial
10:44 <haypo:#afpy> je pense que vu que le développement de virtualenv est très actif, il vaut mieux que ça soit développé en dehors
10:44 <flox:#afpy> virtualenv3 existe (mais pas dans la stdlib)
10:44 <haypo:#afpy> faire entrer un projet dans python, c'est s'assurer qu'il sera toujours désuet :-D
10:44 <ccomb:#afpy> très actif, m'enfin c'est toujours pas releasé pour python3
10:45 <haypo:#afpy> c'est comme setuptools & cie, je me dis que c'est pas plus mal si c'est pas dans python
10:45 <flox:#afpy> ben la version python3 de virtualenv fonctionne (même si elle n'est pas releasé)
10:45 <haypo:#afpy> vaut mieux qu'ils expérimentent en dehors et que seuls les truc super stables entrent dans python
10:46 <ccomb:#afpy> mais c'est relou, quand t'explique comment démarrer un projet ou installer un truc, d'avoir à donner 1 milliars de commandes avec 1 milliard d'outils tiers
10:46 <ccomb:#afpy> alors d'abord t'installes setuptools
10:46 <ccomb:#afpy> ah non pas setuptools, distribute
10:46 <ccomb:#afpy> donc tu fais wget ez_distribute.py
10:46 <ccomb:#afpy> attends, je te donne l'URL
10:46 <ccomb:#afpy> voilà
10:46 <ccomb:#afpy> après tu fais easy_install virtualenv
10:46 <ccomb:#afpy> ah non
10:46 <ccomb:#afpy> tu fais pip install virtualenv
10:47 <flox:#afpy> m'enfin, il serait temps d'unifier setuptools/distribute et d'inclure des gros morceaux dans Python (ce que fait tarek en ce moment)
10:47 <ccomb:#afpy> ah non, d'abord il faut installer pip
10:47 <ccomb:#afpy> easy_install pip
10:47 <ccomb:#afpy> voilà
10:47 <ccomb:#afpy> maintenant pip install virtualenv
10:47 <ccomb:#afpy> ok
10:47 <ccomb:#afpy> maintenant virtualenv --no-site-packages sandbox
10:47 <flox:#afpy> bah, tu linkes sur l'affiche http://python-distribute.org/pip_distribute.png
10:47 <ccomb:#afpy> ayé
10:47 <flox:#afpy> facile :p
10:50 <ccomb:#afpy> à mon avis il vaut mieux que ça soit intégré dans le coeur
10:50 <ccomb:#afpy> ça peut plus évoluer ensuite, mais si c'est plus facile pour tout le monde
10:50 <haypo:#afpy> ccomb: si c'est dans python, c'est super casser couille pour faire évoluer le projet
10:51 <haypo:#afpy> car il faut toujours garder la compatibilité ascendante
10:51 <ccomb:#afpy> ça je m'en fous, c'est votre boulot qu'est difficile, pas le notre :D
10:51 <haypo:#afpy> c'est pas un boulot, je ne suis pas payé pour bosser dans python
10:52 <ccomb:#afpy> je sais bien, mais c'est quand meme un boulot
10:52 <ccomb:#afpy> enfin c'est juste une question de vocabulaire
10:53 <flox:#afpy> il y a 3 PEP qui couvrent des amélioration de distutils: 376, 386 et 390
10:54 <flox:#afpy> on est sur la bonne voie... Pour Python 3.5 on a une chance d'avoir "distribute" dans Python ;)
10:54 <ccomb:#afpy> euh ça risque pas... :P
10:55 <ccomb:#afpy> en tout cas vivement distutils2
10:58 <haypo:#afpy> distutils2 existe déjà, y'a un dépôt mercurial
10:58 <haypo:#afpy> y'a 5 étudiants Google Summer of Code qui vont bosser dessus
10:58 <haypo:#afpy> par contre, là tout de suite, je sais pas dans quel état c'est
11:02 <ccomb:#afpy> c'est en alpha
11:03 <ccomb:#afpy> j'aimerais bien tester rapidement
11:04 <haypo:#afpy> bah juste fait le :)
11:05 <ccomb:#afpy> haypo: un exemple sur sys.argv
11:05 <ccomb:#afpy> $ touch `echo "günayd?n" | iconv -f utf-8 -t iso8859-9`
11:05 <ccomb:#afpy> $ python3.1 -c "import sys; print(sys.argv[1].encode('iso8859-9'))" g*
11:06 <ccomb:#afpy> j'ai fait une connerie ?
11:06 <haypo:#afpy> ccomb: non
11:06 <haypo:#afpy> tu utilises le mauvais encodage
11:06 <haypo:#afpy> tu n'utilises pas surrogateescape
11:06 <ccomb:#afpy> ah
11:06 <haypo:#afpy> 10:35 < haypo> encoding = sys.getfilesystemencoding(); argv_bytes = [arg.encode(encoding, "surrogateescape") for arg in sys.argv]
11:07 <haypo:#afpy> tiens, je vais mettre ça dans ma doc
11:07 <ccomb:#afpy> ça me fait 'charmap' codec can't encode character '\udcfc' in position 1
11:08 <haypo:#afpy> ccomb: la ligne que je t'ai donnée ?
11:08 <ccomb:#afpy> python3.1 -c "import sys; print(sys.argv[1].encode('iso8859-9'), "surrogateescape")" g*
11:09 <ccomb:#afpy> bon, je réessaierai ce soir, je dois faire n'importe quoi
11:09 <haypo:#afpy> euh, relis ton code
11:09 <haypo:#afpy> t'as pas mis la virgule au bon endroit :-)
11:09 <ccomb:#afpy> ah merde oui
11:10 <haypo:#afpy> ccomb: il ne faut pas encoder en iso8859-9 mais en sys.getfilesystemencoding()
11:10 <haypo:#afpy> ensuite, tu peux décoder en iso8859-9 si tu veux
11:10 <ccomb:#afpy> oui c'est ça
11:10 <haypo:#afpy> mais tu peux aussi conserver le type bytes si tu ne veux pas afficher le nom du fichier
11:10 <ccomb:#afpy> en plus dans mon exemple je mélange les " du shell et ceux de python...
11:11 <haypo:#afpy> sys.argv : décodé avec sys.getfilesystemencoding() + surrogateescape -- encoder avec sys.getfilesystemencoding() + surrogateescape --> bytes --- encoder avec iso8859-9 --> str bien encodé
11:13 <haypo:#afpy> ah non mince, c'est locale.getpreferredencoding() pas sys.getfilesystemencoding() (les deux doivent être égaux la plupart du temps je pense)
11:13 <ccomb:#afpy> $ python3.1 -c "import sys; print(sys.argv[1].encode('utf-8', 'surrogateescape').decode('iso8859-9'))" g*
11:13 <ccomb:#afpy> günayd?n
11:14 <ccomb:#afpy> \o/
11:14 <haypo:#afpy> voilà
11:14 <flox:#afpy> c pas très sexy :(
11:14 <flox:#afpy> vive les surrogates
11:14 <haypo:#afpy> par contre, si tu passes "günayd?n" à open(), il va te faire une erreur :-)
11:14 <ccomb:#afpy> si c'est juste pour sys.argv c'est pas très grave
11:14 <haypo:#afpy> car "günayd?n" sera encodé avec sys.getfilesystemencoding() et non pas "iso8859-9" ;-)
11:14 <haypo:#afpy> rigolo non ?
11:15 <ccomb:#afpy> open() prend quoi alors, un str?
11:15 <haypo:#afpy> faudrait que je vois si je pourrais pas créer sys.argvb
11:15 <haypo:#afpy> ccomb: open() accepte str, bytes et int
11:15 <haypo:#afpy> ccomb: je te conseille d'utiliser bytes et ne convertir en str que pour l'*affichage*
11:15 <ccomb:#afpy> ah oui ok, il faut lui filer le bon bytes
11:16 <flox:#afpy> haypo: tu veux pas forker python3 --> python3b ?
11:16 <haypo:#afpy> pour ton problème précis, tu pourrais créer une petite classe Filename qui stocke le nom dans les formats bytes, str et aussi l'encodage :-)
11:16 <haypo:#afpy> flox: lol
11:16 <haypo:#afpy> flox: quand deux chemins se présentent à toi, choisis le plus difficile
11:17 <haypo:#afpy> flox: càd patcher python3 pour avoir les deux (bytes et str+surrogates)
11:17 <haypo:#afpy> ccomb: d'ailleurs, tu peux aussi convertir str+surrogates (sys.argv non modifié), et ne faire .encode().decode() que lors de l'affichage
11:18 <haypo:#afpy> flox: "python3 --> python3b" existe déjà pour info
11:18 <haypo:#afpy> flox: ça s'appelle python2 \o/
11:19 <haypo:#afpy> python2 est pas trop mal pour la gestion d'unicode. mais y'a des trucs méga casse couille comme le fait qu'Exception ne permet pas de stocker un message unicode
11:19 <haypo:#afpy> les messages IOError() sont de type str d'ailleurs, c'est dommage
11:33 <solevis:#afpy> matin
14:18 <yotaff:#afpy> ccomb: pingf
14:18 <ccomb:#afpy> yotaff: pongf
14:18 <yotaff:#afpy> ccomb: comment on met la page en paysage dans inkscape ? :)
14:18 <ccomb:#afpy> j'étais en train de penser à toi, c'est émouvant, non ? :P
14:19 <yotaff:#afpy> ahaha
14:19 <yotaff:#afpy> je sais pas, ca dépend a quoi tu pensais :)
14:19 <ccomb:#afpy> fichier -> propriétés du document
14:19 <yotaff:#afpy> oO(t1 j'ai doit appelé l'autre connard)Oo
14:20 <ccomb:#afpy> ou sinon c'est le bouton tout en haut à droite
14:20 <yotaff:#afpy> ah super ca marche
14:20 <yotaff:#afpy> merci :)
14:20 <ccomb:#afpy> :) non je pensais aux buildbots
14:20 <yotaff:#afpy> je m'essaye a inkscape pour faire des trucs un peu plus beau que simplemen un traitement de texte
14:20 <yotaff:#afpy> mais bon je suis merde fini dans ces trucs
14:20 <yotaff:#afpy> je suis overbooké jusqu'a agile france
14:21 <yotaff:#afpy> je croule sous le taff la
14:21 <yotaff:#afpy> (littéralement)
14:21 <ccomb:#afpy> sinon t'as juste à m'ouvrir un accès ssh root
14:21 <yotaff:#afpy> donc dans 2s pour la réu
14:21 <yotaff:#afpy> wai, faut que je fasse une redirection ssh
14:21 <yotaff:#afpy> si j'ai 15mn je fais ca
14:21 <yotaff:#afpy> (ce sont des vms)
14:21 <ccomb:#afpy> ok
14:21 <yotaff:#afpy> au pire, je te donne un compte sur le dom0
14:21 <yotaff:#afpy> suffit de rebondir
14:22 <yotaff:#afpy> temporairement le temps de faire la redir
14:22 <ccomb:#afpy> je sais pas trop comment buildbot gere ça, sinon
14:22 <ccomb:#afpy> faut que le master et le slave puissent communiquer
14:23 <ccomb:#afpy> un tunnel ssh
14:24 <miniwark:#afpy> yotaff: inkscape pour de la mise en page ? essaye plutot Scribus pour ça non ?
14:24 <yotaff:#afpy> ccomb: euh ils communiquent en réseau
14:24 <yotaff:#afpy> réseau interne
14:24 <yotaff:#afpy> pas de soucis
14:24 <yotaff:#afpy> en lan (ip quoi)
14:24 <yotaff:#afpy> miniwark: pour faire des graphes
14:24 <yotaff:#afpy> dessins
14:24 <ccomb:#afpy> oui mais je pensais utiliser le master afpy et faire seulement des slaves
14:24 <ccomb:#afpy> ça centralise et ça permet d'envoyer des mails
14:25 <miniwark:#afpy> yotaff: ok bon courage :)
15:54 <yotaff:#afpy> bon
15:54 <yotaff:#afpy> ccomb dans l'équipe ZTK
15:54 <yotaff:#afpy> je sais qui je vais faire chier :)
16:01 <haypo:#afpy> c'est quoi ZTK ?
16:01 <haypo:#afpy> Tk pour Zope ?
16:02 <gawel:#afpy> pour zizi top koncert
16:16 <flox:#afpy> kaziment... une sorte de Zope Standard Library
16:33 <yotaff:#afpy> haypo: Zope Toolkit, en gros le nouveau de Zope (le framework est viré, il ne reste qu'un ensemble de lib)
16:33 <yotaff:#afpy> -de
16:34 <yotaff:#afpy> Zope avec les composants zope.app.*, devient bluebream
16:34 <yotaff:#afpy> bref que du bon
16:34 <yotaff:#afpy> ZTK c'est le core de BlueBeam, Grok ou Repoze BFG
16:34 <yotaff:#afpy> la couche basse
16:35 <haypo:#afpy> pour moi qui suit Zope de très loin, je trouve ça très compliqué Zope
16:35 <yotaff:#afpy> bof
16:35 <haypo:#afpy> y'a plein de noms qui partent dans tous les sens
16:35 <yotaff:#afpy> wai, c'est vrai
16:35 <yotaff:#afpy> ca s'appelle zope depuis
16:35 <haypo:#afpy> d'abord j'apprend que Zope est découpé en petits bouts
16:35 <yotaff:#afpy> 1998
16:35 <haypo:#afpy> après j'apprend qu'il existe un gros bout ("BlueBeam" ?)
16:35 <haypo:#afpy> puis qu'il existe plusieurs gros ou moyen bouts
16:35 <haypo:#afpy> finalement, je comprend plus rien :-)
16:36 <yotaff:#afpy> wai, faut dire que tu ne fais pas trop d'effort non ? :)
16:36 <yotaff:#afpy> résumé en 5 lignes
16:36 <haypo:#afpy> si, je fais beaucoup d'efforts
16:36 <haypo:#afpy> pour ne rien comprendre :-)
16:36 <yotaff:#afpy> zope 1, puis Zope2, qui était monolithique
16:36 <yotaff:#afpy> ils ont découpés en 180 eggs
16:37 <yotaff:#afpy> ce qui a permit l'émergeance de plusieurs projets autour de Zope comme BFG et Grok
16:37 <haypo:#afpy> ZTK c'est les 180 eggs ?
16:37 <yotaff:#afpy> ils ont décidé de bien séparer les libs utiles a tous => ZTK
16:37 <gawel:#afpy> non, que 3 barbus
16:37 <yotaff:#afpy> et le projet Zope change de nom et s'appelle BlueBream
16:38 <yotaff:#afpy> trés compliqué hein :)
16:38 <flox:#afpy> le principal lien entre Zope2 et Zope3, c'est la ZODB
16:38 <yotaff:#afpy> bon forcement, faut écouter des phrases comme la précédente, ca evite d'etre perdu
16:38 <yotaff:#afpy> faut pas
16:38 <yotaff:#afpy> Zope 2: un projet, Zope3 : un autre projet
16:39 <yotaff:#afpy> y'a pas de lien
16:39 <yotaff:#afpy> ou alors, c'est comme dire que Django et RoR ont un lien parce qu'il utilise mysql
16:39 <flox:#afpy> (si tu omet Five et la ZODB, tu as raison)
16:39 <yotaff:#afpy> ils utilisent
16:39 <haypo:#afpy> yotaff: pourquoi tu écris "Zope3" ? je croyais que c'était interdit d'écrire "Zope3" ?
16:39 <yotaff:#afpy> ils ont fait la connerie de mettre le meme nom pour une pauvre histoire de marketing
16:40 <flox:#afpy> Zope 3 est mort, vive Bluebream
16:40 <yotaff:#afpy> (qu'ils ne maitrisent pas d'ailleurs)
16:40 <yotaff:#afpy> haypo: pas vraiment, Zope 3.4.1 va sortir, disons qu'il est maintenance exclusivement, aucun dev n'est prévu
16:40 <yotaff:#afpy> mais il n'est pas mort dans le sens ou pas mal de gens ont dév dessus
16:41 <yotaff:#afpy> mais ca a pas bougé depuis longtemps :)
16:41 <haypo:#afpy> "Zope 3 est mort" "Zope 3.4.1 va sortir" et après on me dit que c'est moi qui fait pas d'effort
16:41 <haypo:#afpy> vous vous contridiez les gars
16:41 <haypo:#afpy> contredisez*
16:41 <yotaff:#afpy> haypo: cobol est mort, mais il est toujours utilisé :)
16:41 <flox:#afpy> ah bon? Zope3 n'est pas mort
16:41 <flox:#afpy> on m'aurait menti
16:41 <flox:#afpy> http://pypi.python.org/pypi/bluebream#introduction
16:42 <flox:#afpy> BB, formerly known as Zope 3
16:42 <haypo:#afpy> bon. disons que ZTK est un petit ensemble d'oeuf. BlueBeam c'est quoi alors ?
16:42 <flox:#afpy> bluebream c'est l'omelette
16:42 <flox:#afpy> (avec les herbes et les oignons)
16:43 <haypo:#afpy> BB contient du code en plus de ZTK pour lier les oeufs ?
16:43 <haypo:#afpy> Grok c'est une autre sauce alors ?
16:43 <haypo:#afpy> "Repoze BFG" c'est quoi alors ?
16:43 <haypo:#afpy> une 3e type d'omelette ?
16:44 <flox:#afpy> BFG, c'est un autre encore (wsgi-friendly, si je me souviens bien)
16:44 <haypo:#afpy> Grok & Repoze BFG utilisent la ZODB ?
16:44 <flox:#afpy> grok, oui (par défaut)
16:44 <haypo:#afpy> flox: autre quoi ?
16:44 <flox:#afpy> autre framework basé sur des technologies "Zope" (ZTK)
16:44 <haypo:#afpy> "BlueBream implements the WSGI"
16:44 <flox:#afpy> ah, ok (j'étais resté sur de l'ancien)
16:45 <yotaff:#afpy> haypo: BFG utilise ce que tu veux, ZODB ou autre
16:45 <haypo:#afpy> moi je veux rien. j'esssaye juste de comprendre
16:45 <yotaff:#afpy> comme pour le ZCML
16:45 <flox:#afpy> j'ai travaillé avec Zope 3 pendant 2 ans et Grok l'année dernière
16:46 <flox:#afpy> BFG, j'ai pas beaucoup creusé
16:46 <flox:#afpy> (et Bluebream, successeur de Zope3, je n'ai pas eu le temps de tester davantage)
16:47 <haypo:#afpy> je me souviens d'une présentation Grok de 1h (qui m'avait semblé durer 2h) où on m'a expliqué qu'on écrivant à peine 10 fichiers XML incompréhensible on peut afficher "Hello World!" et ça c'est quand même génial !
16:47 <haypo:#afpy> et soit disant c'était plus que simple que Zope (Zope2 je pense)
16:47 <haypo:#afpy> j'ose pas imaginer la complexité de Zope du coup :-)
16:47 <flox:#afpy> il y a sans doute une page qqpart pour expliquer les différences et les similitudes entre les différents frameworks "ZTK-based"
16:48 <haypo:#afpy> j'sais pas, mais Django c'est simple quand même. Sur quels points Zope est préférable à Django ? pour justifier le coût exhorbitant du projet et surtout de la maintenance ?
16:49 <haypo:#afpy> je remarque surtout que les utilisateurs de Zope sont toujours fier de dire "la nouvelle version de Zope est plus simple que la précédente"
16:49 <flox:#afpy> je pourrais pas défendre Zope, même si j'y ai appris bcp de choses
16:49 <haypo:#afpy> en même temps, vu de là où ils partaient, c'est dure de faire plus compliqué non ?
16:50 <haypo:#afpy> « ... [Zope 3] a consisté à créer une architecture modulaire et *innovante*, la « Zope Component Architecture » (ZCA) » pour citer ccomb
16:50 <haypo:#afpy> mince, j'ai coupé un bout. « ... « Zope 3 », a consisté à créer une architecture modulaire et innovante, la « Zope Component Architecture » (ZCA), puis à découper proprement Zope et une multitude de paquets utilisant cette architecture. »
16:52 <haypo:#afpy> peut-être que je devrais soigner le mal par le mal et monter un site Zope3^WBlueBream pour voir
16:53 <haypo:#afpy> yotaff: "Flavours of Zope" http://ozzope.org/what-is-zope
16:54 <flox:#afpy> la ZCA, c'est 'achement bien ... même twisted l'utilise ;)
16:54 <flox:#afpy> http://twistedmatrix.com/documents/current/core/upgrades/2.0/components.html
16:54 <haypo:#afpy> flox: pour info, je déteste Twisted. savoir que Zope est lié à Twisted me donne encore moins envie d'y toucher :-)
16:54 <flox:#afpy> m'enfin les principe de Zope3 sont très intéressants et pédagogiques
16:55 <flox:#afpy> mais bon, j'ai retiré Grok de mon projet actuel.... et j'utilise Werkzeug+Jinja+SQLAlchemy maintenant
16:55 <haypo:#afpy> Twisted est un bon exemple d'antipattern (programmation spaghetti)
16:55 <flox:#afpy> question pratique .... :D
16:56 <haypo:#afpy> flox: j'ai conseillé SQLAlchemy à des collègues, ils ont pris Elixir car semble-t-il c'est plus simple pour les jointures
16:56 <haypo:#afpy> flox: tu sais si c'est bien Elixir ?
16:57 <flox:#afpy> a priori c'est une surcouche déclarative sur SQLAlchemy
16:57 <flox:#afpy> (il me semble)
16:57 <gawel:#afpy> ouais
16:57 <flox:#afpy> bon d'accord je viens de voir la première phrase de la page pypi... c'est exactement ça
16:57 <gawel:#afpy> sert plus a grand chose
16:58 <flox:#afpy> oui, SA fait du déclaratif aussi
16:58 <haypo:#afpy> ça semble beaucoup dépendre des versions
16:59 <haypo:#afpy> je veux dire que SQLAchemy évolue vite et il faut la dernière version pour avoir les trucs sympa (à ce que j'ai compris)
16:59 <haypo:#afpy> (au boulot, on bosse avec Debian Stable :-))
16:59 <flox:#afpy> "There are three very common ways to use SQLAlchemy: declarative ORM, manual ORM and SQL"
17:00 <haypo:#afpy> j'ai surtout remarqué qu'Elixir rajoute une couche à SQLAchemy qui est déjà une grosse couche
17:00 <haypo:#afpy> du coup, quand il y a une erreur, il faut s'accrocher...
17:00 <flox:#afpy> "thin" ils disent
17:00 <flox:#afpy> m'enfin faut se méfier de la plaquette commerciale
17:00 <flox:#afpy> :)
17:02 <haypo:#afpy> à ce que je lis, BFG est comme Django comparé à Pylon : c'est un truc tout nu qu'il faut habiller avec ce qu'on veut
17:04 <haypo:#afpy> enfin, rendons à césar ce qui appartient à césar : Zope permet à pas mal de développeur de gagner des sous en codant en Python et surtout on peut troller Python grâce à Zope !
17:05 <gawel:#afpy> grace a django aussi
17:05 <flox:#afpy> l'intérêt de Zope 2 actuellement, c'est surtout Plone (je pense)
17:06 <flox:#afpy> et c'est le framework qui oblige à garder sous le coude Python 2.4 :)
17:06 <gawel:#afpy> ce qui est bien dans django c'est que quand tu fais une faute de frappe dans une template ca raise pas. du coup personne se plaind quand tu fais de la merde
17:07 <ccomb:#afpy> euh non, c'est du python 2.6 maintenant
17:07 <ccomb:#afpy> gawel: comme PHP :D
17:07 <flox:#afpy> c'est récent, mais beaucoup de clients n'ont pas migrés
17:07 <ccomb:#afpy> flox: *aucun* client tu veux dire
17:07 <flox:#afpy> et migrer une application Zope, c'est rémunérateur :D
17:08 <ccomb:#afpy> c'est à la hauteur de la chierie
17:08 <flox:#afpy> j'imagine ...
17:08 <flox:#afpy> je vais contacter mon ancien employeur pour lui proposer de migrer son appli :D
17:10 <ccomb:#afpy> mais sinon zope c'est pas compliqué
17:10 <ccomb:#afpy> zope 2 tout seul, c'est super simple et c'est génial
17:10 <ccomb:#afpy> zope 3 c'est aussi simple et aussi génial, mais ça n'a rien à voir
17:11 <ccomb:#afpy> ce qui est compliqué c'est plone
17:14 <flox:#afpy> oui mais Plone est plutôt complet (on dit "bloated"?)
17:16 <flox:#afpy> ce serait bien d'avoir un Plone plus modulaire... où on puisse facilement remplacer la ZODB par SQLAlchemy
17:16 <flox> (peut-être que c'est faisable, mais à l'époque je n'ai pas trouvé)
17:16 <gawel> par couchdb plutot
17:16 <gawel> non
17:17 <flox> ou couchdb... mais l'idée c'est d'utiliser un backend plus ouvert qui soit plus facilement "scalable"
17:18 <flox> même si la ZODB a quelques possiblités (ZEO, RelationalStorage)
17:27 <flox:#afpy> avec Grok on peut utiliser SqlAlchemy (megrok.rdb) ... c'est tout l'intérêt de la "Component Architecture"
17:28 <flox:#afpy> (et l'inconvénient de Plone qui est basé sur Zope2 et qui ne peut pas évoluer aussi facilement)
17:48 <ccomb:#afpy> tarek: ping