Avant
class IndexPage(BasePage):
def iter_videos(self):
span_list = self.parser.select(self.document.getroot(), 'span#miniatura')
for span in span_list:
a = self.parser.select(span, 'a', 1)
url = a.attrib['href']
_id = re.sub(r'/videos/(.+)\.html', r'', url)
video = YoujizzVideo(_id)
video.thumbnail = BaseImage(span.find('.//img').attrib['data-original'])
video.thumbnail.url = video.thumbnail.id
title_el = self.parser.select(span, 'span#title1', 1)
video.title = to_unicode(title_el.text.strip())
time_span = self.parser.select(span, 'span.thumbtime span', 1)
time_txt = time_span.text.strip().replace(';', ':')
hours, minutes, seconds = 0, 0, 0
if ':' in time_txt:
t = time_txt.split(':')
t.reverse()
seconds = int(t[0])
minutes = int(t[1])
if len(t) == 3:
hours = int(t[2])
elif time_txt != 'N/A':
raise BrokenPageError('Unable to parse the video duration: %s' % time_txt)
video.duration = datetime.timedelta(hours=hours, minutes=minutes, seconds=seconds)
yield video
Après
class IndexPage(HTMLPage):
@method
class iter_videos(ListElement):
item_xpath = '//span[@id="miniatura"]'
next_page = Link(u'//a[text()="Next »"]')
class item(ItemElement):
klass = BaseVideo
obj_id = Regexp(Link('.//a'), r'/videos/(.+)\.html')
obj_title = CleanText('.//span[@id="title1"]')
obj_duration = Duration(CleanText('.//span[@class="thumbtime"]//span'), default=NotAvailable)
obj_nsfw = True
def obj_thumbnail(self):
thumbnail = BaseImage(Attr('.//img', 'data-original')(self))
thumbnail.url = thumbnail.id
return thumbnail
# NIH ?
Posté par Moonz . Évalué à 3. Dernière modification le 20 mars 2014 à 22:33.
Sinon, pourquoi ne pas avoir tout simplement utilisé PyQuery ? Typiquement, en PyQuery,
c’est
Et les trucs spécifiques que PyQuery sait pas faire par défaut (typiquement: regex) peuvent parfaitement être implémentés dans
PyQuery.fn
[^] # Re: NIH ?
Posté par rzx . Évalué à 2.
En fait, je t'invite à lire ce billet qui explique que l'apport n'est pas tant au niveau des sélecteurs (xpath marche très bien), mais de toute la structuration et la simplification de l'écriture d'un module weboob.
[^] # Re: NIH ?
Posté par Moonz . Évalué à 2.
PyQuery ce n’est pas que des sélecteurs, c’est aussi des outils pour manipuler plus facilement le DOM, exactement dans l’idée des fonctions type CleanText. C’est à ça que je faisais référence quand je parlais de pyquery, pas du boulot autour de ListElement qui me semble effectivement une bonne idée
Et les sélecteurs CSS c’est quand même vachement plus pratique que xpath dans 99% des cas :)
[^] # Re: NIH ?
Posté par rzx . Évalué à 2.
Je te rejoins sur le fait que les sélecteurs CSS sont pratiques et lisibles, néanmoins xpath est très puissant et permet d'être plus fin. Il faudrait peut-être que l'on permette les deux.
Avoir gardé l'utilisation de lxml directement est davantage historique, néanmoins PyQuery ne répondrait pas à la problématique tel quel, car ce que permettent de faire les filtres ici est de définir un chaînage a priori pour l'appliquer sur chaque élément de la liste lors du parsing, alors que PyQuery va effectuer la sélection immédiatement.
[^] # Re: NIH ?
Posté par laurentb (site web personnel) . Évalué à 1.
J'ai regardé PyQuery rapidement.
PyQuery utilise lxml comme nous ; d'ailleurs utiliser autre chose serait une mauvaise idée (on est justement en train d'abandonner l'idée des multiples parsers de HTML).
C'est plutôt intéressant (particulièrement la possibilité de définir une fonction personnalisée), mais l'argument en faveur du NIH, c'est que utiliser des librairies de haut niveau nous a créé beaucoup de désagréments, et avoir le contrôle direct sur le parsing et pouvoir le faire évoluer suivant nos besoins est très important.
Quant à l'utilisation de filtres CSS, c'est déjà possible avec lxml (enfin, ça a été séparé vers cssselect).
[^] # Re: NIH ?
Posté par Moonz . Évalué à 2.
cssselect je le trouve vraiment désagréable à l’utilisation, mais c’est peut-être une question de goût.
J’ai pas regardé côté browser 2, mais en fait ce que je voulais dire c’est qu’il aurait été plus logique (enfin, de mon point de vueu) d’« hériter » de PyQuery (qui « hérite » de lxml.etree) plutôt que directement de lxml.etree.
(j’utilise « hérite » entre guillemets parce que je sais pas si vous faites de l’héritage ou de la composition)
[^] # Re: NIH ?
Posté par Florent Fourcot . Évalué à 4.
Non, CleanText et doc(".title1").text() de PyQuery ne sont pas équivalents d'après ce que je vois. CleanText ne fait pas que récupérer le texte, mais le nettoie (comme son nom l'indique).
PyQuery ne serait ici utile que pour récupérer les données, ce que beaucoup d'autres outils savent faire aussi. Ils y ajoutent l'écriture/modification d'un document, mais ce n'est pas très intéressant dans notre cas (je base mon opinion sur la lecteur de leur doc)
# Confusionnantissant
Posté par Maclag . Évalué à 10.
Un journal sur weboob qui parle de "Browser", je croyais que weboob étais en train d'intégrer un browser web out of browser.
Ça a failli faire exploser la zone de mon cerveau qui traite de métaphysique! (Là y'a juste eu une fuite, pas de dégâts, la zone est petite…)
Pourriez faire gaffe non!?
[C'était un commentaire en direct de la Ligue des Inutiles du VEndredi, donc un commentaire en direct-LIVE]
[Cette signature vous était offerte par la Ligue des Blagues Pourries, la LBP, c'est pourri comme sigle, non?]
[^] # Re: Confusionnantissant
Posté par fravashyo . Évalué à 10.
moi aussi j'ai pas compris. Weboob serait-il tombé dans le politiquement correct en se renommant "Browser 2" ? Là ça serait déçevant. Pourquoi ne pas l'appeler "Brouteur", et créer des applications "brout ton chatt" pour aller sur caramail, "brout ton minou" pour visiter lolcatz.com, "brout ton poireau" pour feuilleter le catalogue rustica…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Confusionnantissant
Posté par laurentb (site web personnel) . Évalué à 2.
Browser (1 ou 2) est un composant de Weboob. Il est d'ailleurs possible de l'utiliser comme une librairie indépendante.
Avoir un nom plus identifiable est peut-être une bonne idée pour le rendre plus visible à ceux qui chercheraient un remplacement à Mechanize. Browser2 est un remplaçant de Mechanize et Browser1; Browser1 utilisant Mechanize et Browser2 utilisant requests (qui est plus bas niveau).
# Diff
Posté par Sygne (site web personnel) . Évalué à 10.
Àmha, de même qu'un bon journal bookmark devrait se contenter d'un unique lien, un bon journal diff devrait se contenter d'un unique patch.
C'était mieux à vent. J'apprécie néanmoins la nimage.
# Nimages
Posté par bubar🦥 (Mastodon) . Évalué à 0.
ou presque
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.