Le fait de pouvoir tout mettre dans les list|hash en python pousse les devs a faire des API minimalistesimbitables, où la notion d'abstraction est un lointain souvenir. Au hasard choisissons un petit bout de code utilisant imaplib, http://www.python.org/doc/2.5.2/lib/imap4-objects.html . Nous voulons simplement lister tout les messages non lu et matcher sur un sujet.
server = imaplib.IMAP4(host)
server.login(user, passwd)
inbox = server.select()
typ, data = server.search(None, 'UNSEEN')
urls = []
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
for line in data[0][1].split("\r\n"):
# header & body part
(junk, sep, url) = line.partition("magic_key:")
if not url is "":
urls.append(url)
return urls
C'est sur ca fait facilement 5x moins de ligne que son équivalent en javamail. Par contre on peut le voir, c'est tout aussi pénible à utiliser. Je préfère écrire 5x plus de lignes, mais manipuler des abstractions et que je sache ce que je manipule. Je m'explique:
typ, data = server.search(None, 'UNSEEN')
Qu'est ce que peut bien me retourner server.search ? Allons voir la doc: Search mailbox for matching messages. charset may be None, in which case no "CHARSET" will be specified in the request to the server. The IMAP protocol requires that at least one criterion be specified; an exception will be raised when the server returns an error. . Je suis bien avancé aucune idée de ce que peuvent être typ ou data. Moi je voulais manipuler une liste de message non lu. Il me retourne une structure dont je ne sais rien...
En "printant" la structure on découvre ce qui nous intéresse. C'est super pro comme démarche... On découvre qu'il "suffit" de faire un data[0].split() pour avoir tout les ID des messages. Bon si ils changent la map dans une prochaine release tout va péter silencieusement mais c'est une autre histoire.
Après on veut manipuler les messages. Rebelote on va voir la doc Fetch (parts of) messages. message_parts should be a string of message part names enclosed within parentheses, eg: ""(UID BODY[TEXT])"". Returned data are tuples of message part envelope and data.
Encore une fois aucune abstraction, on me balance un tuple dont l'un des éléments est le message sous forme d'une string. C'est un peu plus précis mais pas trop quand même. Et le message surtout je me démerde avec ma string hein.
Moi tout ce que je voulais c'est "Pour chaque message non lu chercher dans le corp du message les lignes contenant magic_key et en extraire la suite".
Le code python est peut être beaucoup plus court, mais a utiliser il est super pénible, casse gueule. Les notions d'objet et d'abstraction sont bien loin...
[^] # Re: Critique
Posté par ckyl . En réponse au journal Explorez les richesses du langage Python. Évalué à 6.
server = imaplib.IMAP4(host)
server.login(user, passwd)
inbox = server.select()
typ, data = server.search(None, 'UNSEEN')
urls = []
for num in data[0].split():
typ, data = server.fetch(num, '(RFC822)')
for line in data[0][1].split("\r\n"):
# header & body part
(junk, sep, url) = line.partition("magic_key:")
if not url is "":
urls.append(url)
return urls
C'est sur ca fait facilement 5x moins de ligne que son équivalent en javamail. Par contre on peut le voir, c'est tout aussi pénible à utiliser. Je préfère écrire 5x plus de lignes, mais manipuler des abstractions et que je sache ce que je manipule. Je m'explique:
typ, data = server.search(None, 'UNSEEN')Qu'est ce que peut bien me retourner server.search ? Allons voir la doc: Search mailbox for matching messages. charset may be None, in which case no "CHARSET" will be specified in the request to the server. The IMAP protocol requires that at least one criterion be specified; an exception will be raised when the server returns an error. . Je suis bien avancé aucune idée de ce que peuvent être typ ou data. Moi je voulais manipuler une liste de message non lu. Il me retourne une structure dont je ne sais rien...
En "printant" la structure on découvre ce qui nous intéresse. C'est super pro comme démarche... On découvre qu'il "suffit" de faire un
data[0].split()pour avoir tout les ID des messages. Bon si ils changent la map dans une prochaine release tout va péter silencieusement mais c'est une autre histoire.Après on veut manipuler les messages. Rebelote on va voir la doc Fetch (parts of) messages. message_parts should be a string of message part names enclosed within parentheses, eg: ""(UID BODY[TEXT])"". Returned data are tuples of message part envelope and data.
Encore une fois aucune abstraction, on me balance un tuple dont l'un des éléments est le message sous forme d'une string. C'est un peu plus précis mais pas trop quand même. Et le message surtout je me démerde avec ma string hein.
Moi tout ce que je voulais c'est "Pour chaque message non lu chercher dans le corp du message les lignes contenant magic_key et en extraire la suite".
Le code python est peut être beaucoup plus court, mais a utiliser il est super pénible, casse gueule. Les notions d'objet et d'abstraction sont bien loin...
J'aime pas du tout l'API de javamail mais entre imaplib:
http://www.python.org/doc/2.5.2/lib/module-imaplib.html
http://www.python.org/doc/2.5.2/lib/imap4-objects.html
et javamail:
http://java.sun.com/products/javamail/javadocs/com/sun/mail/(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Fo(...)
http://java.sun.com/products/javamail/javadocs/javax/mail/Me(...)
je sais lequel est plus facile à manipuler et que c'est totalement indépendant de devoir écrire 50 lignes de plus...