Produits Entr'ouvert » Publik

Je suis intéressé.

http://git.entrouvert.org/ods.git/

J'ai repris wcs.qommon.ods en partie (je n'ai pas réussi à voir l'effet de la déclaration de l'élément table:table-column et des styles DateColumn/DateTimeColumn, si ça reste utile je le remettrais) pour l'écriture mais avec une API qui ressemble plus à csv.writer() et la partie lecture est originale, avec par rapport à csv la possibilité de conserver le typage des cellules (et donc d'obtenir des int, date, datetime, etc.. ça n'est pas obligatoire mais ça donne quelque chose de symétrique avec la partie écriture).

Les deux fonctionnent en mode push/pull pour ne consommer aucune mémoire ou presque.

Là ce qu'il faudrait surtout c'est plus de fichiers tests pour les tests en lecture. Je note déjà que rowspan/colspan ne sont pas supportés (et certainement plein d'autres choses).

Quand j'écrivais "petit module", je pensais plutôt en fait à un "package", qui ne soit pas fourre-tout, on aurait trouvé un nom, genre tabularfile, et ça aurait ouvert des directions supplémentaires, je pense là à y gérer les CSV avec tout le brol bom/encodage/etc., ça serait allé dans une classe AutoReader, ce qui est le truc qui permettrait à mon sens in fine de retirer cette partie de nos applications.

Là le nom fourre-tout entraine pour moi une obsolescence déjà programmée, à la djommon dans le passé.

Frédéric Péters a écrit :

On devrait avoir un module à l'API proche de l'API des CSV, qui fonctionne et point, sans mille dépendances etc. qu'on utiliserait, et on arrêterait avec les CSV.

Je veux bien mais si l'objectif était de faire un tablib en mieux (sans le foutoir dans vendor/ et les performances aléatoires) il fallait l'écrire dès la description; là ça sonnait plutôt comme « Hors d'ODS, point de salut ». Là je suis aller plus loin en voulant coller à ce que fait w.c.s. pour ses exports, faut voir l'API qu'on veut, on peut s'en tenir pour l'API générique à du texte en entrée/texte en sortie ou alors prévoir un minimum de sérialisation/détection de type pour CSV (genre int, float, date iso8601 et datetime iso8601).

Sur le nom, je n'ai pas de souci à passer à tabularfile, sauf que ça nous met pas mal en avant du pypi avec tablib, pyexcel et leurs copains; mais je pense aussi qu'au delà des expériences djommon/qommon on a un besoin de partager du code, genre les filtres ou les bouts de code qu'on copie partout sans en maintenir la cohérence comme l'API de signature de Publik, qui diffère d'ailleurs maintenant entre wcs et les autres briques.

Oui, c'est « Quand j'écrivais "petit module", je pensais plutôt en fait à un "package" » qui a mené confusion, ok. (aussi, ce ticket n'avait pas de personne assignée mais je n'imaginais pas qu'il soit pris sans discussion, et j'ai pris le "je suis intéressé" comme étant ton intérêt que quelqu'un/e prenne le ticket, pas comme quoi tu allais le prendre).

En même temps j'écrivais "lecture", donc l'interprétation de ce que j'ai écrit a de toute façon été assez libre.

Je n'ai pas compris ton commentaire sur le nom, c'est la crainte de faire un module qui soit utilisé par d'autres, ou de guider d'autres indirectement d'autres personnes vers un module qui ne ferait pas "tout" ?

Sur ce dernier point, ma réponse pourrait être d'en taper en description "Opiniated read/write support of tabular formats", le "opiniated" étant le truc à la mode pour proclamer qu'on gère comme on veut.

Bref, je suis pour un module dédié, d'abord à la lecture, d'abord à l'ods (mais en fait tout de suite au csv pour remplacer d'un coup la lecture CSV qu'on a dans nos modules, sans introduire deux modes, csv compat puis ods nouveau).

Frédéric Péters a écrit :

Oui, c'est « Quand j'écrivais "petit module", je pensais plutôt en fait à un "package" » qui a mené confusion, ok. (aussi, ce ticket n'avait pas de personne assignée mais je n'imaginais pas qu'il soit pris sans discussion, et j'ai pris le "je suis intéressé" comme étant ton intérêt que quelqu'un/e prenne le ticket, pas comme quoi tu allais le prendre).

En même temps j'écrivais "lecture", donc l'interprétation de ce que j'ai écrit a de toute façon été assez libre.

Je n'ai pas compris ton commentaire sur le nom, c'est la crainte de faire un module qui soit utilisé par d'autres, ou de guider d'autres indirectement d'autres personnes vers un module qui ne ferait pas "tout" ?

J'ai une haute opinion des annuaires de paquets, habitué à CPAN dans ma jeunesse, pypi n'a pas le niveau d'organisation et de qualité de CPAN en général mais je vois d'un mauvais oeuil de s'approprier un terme générique comme tabularfile (ce qu'a fait tablib) et de ne pas mener le projet sous-entendu à bien, si ça s'appelle eo-tablib, ça me gêne moins.

Sur ce dernier point, ma réponse pourrait être d'en taper en description "Opiniated read/write support of tabular formats", le "opiniated" étant le truc à la mode pour proclamer qu'on gère comme on veut.

Mouais.. ça prouve juste que les pythoneurs ne sont pas des gens très sérieux.

Bref, je suis pour un module dédié, d'abord à la lecture, d'abord à l'ods (mais en fait tout de suite au csv pour remplacer d'un coup la lecture CSV qu'on a dans nos modules, sans introduire deux modes, csv compat puis ods nouveau).

• détection du type de fichier ODS ou CSV, avec gestion BOM et dialect
• pas de détection du type des colonnes

Pour le nom de fait le namespacing est rare (genre sorl.thumbnail dans ce qu'on utilise, mais un peu au-delà, les modules plone, eux, sont généralement namespacés); mais clairement oui quand j'écris "tabularfile" c'est bien en imaginant "mener le projet sous-entendu à bien"; et quand je précise le "opiniated" par la suite, c'est pour me libérer des "sous-entendus" tiers.

(et je n'aime pas vraiment le préfixe eo qui attache (trop) le module à l'entreprise).

Mais si tabularfile pose vraiment soucis, des variantes différentes / plus longues peuvent être imaginées.

https://jenkins.entrouvert.org/job/tabularfile/

http://git.entrouvert.org/tabularfile.git/