[weboob] [weboob - Feature #403] ICapVideo may support paths

Romain Bignon romain at peerfuse.org
Fri Jan 21 11:41:13 CET 2011


Salut,

Désolé, je me replonge dans le sujet deux mois après.

On 29/Nov - 21:38, Nicolas Duhamel wrote:
> Je retourne des listes dans l'implantation actuelle, puisque c'est
> la manière la
> plus simple, mais rien n’empêche de retourner des generator, comme
> je compte faire
> pour le backend alloshowtv avec la liste des séries, on a donc pas
> forcément tous les
> objets d'un coup.

Effectivement, je suis d'accord que ça peut être bien d'avoir des générateurs
plutôt que des listes, le seul problème c'est qu'on a déjà tout un système en
place pour gérer que la fonction retourne un générateur. Par contre si elle
retourne un tuple de générateurs, ce n'est plus du tout la même chose.

Parce que l'idée de bcall (la fonction do()), c'est qu'à chaque fois qu'un
résultat arrive, on l'envoi à l'application qui itère de façon bloquante, ou qui
reçoit chaque objet dans un callback.

Ce fonctionnement extrêmement pratique ne peut plus fonctionner si l'on a deux
générateurs, ou alors il faut réimplémenter le tout pour pouvoir donner deux
callbacks, etc.

Ou alors ce que je peux te proposer, c'est d'avoir un attribut à la méthode qui
permet de filtrer les résultats. Si on ne donne rien, ça retourne les
« dossiers » et les « fichiers », et tu as ONLY_FILES et ONLY_FOLDERS, dans les
cas où l'on ne veut que l'un des deux.

Et de manière générale, on peut considérer que, si l'on récupère la totalité, on
a d'abord les dossiers et après les fichiers.

> On ignore tant qu'on a pas parcouru l'objet retourné si
> - le path contient d'autre path
> - le path contient des objets
> - en quelle quantité
> 
> En utilisant un objet iterable donc qui peu se comporter exactement
> comme tu
> le demande, mais qui possède également deux attributs, paths et
> content, qui sont soit
> des listes soit des generator, on conserve ces informations.
> Si l'attribut est une liste on connait ça taille, si c'est un
> generator on en
> conclus qu'il est potentiellement très grand, et on sait tout de
> suite si il est nul.

Est-ce que c'est une information réellement importante ?

Romain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.symlink.me/pipermail/weboob/attachments/20110121/fe126a36/attachment.sig>


More information about the weboob mailing list