Dans le cadre d'un projet, j'ai eu besoin d'un module pour analyser et modifier les caractères complexes de certains systèmes d'écriture, en particulier en hébreu, grec ancien ou sanskrit. Mon code commence à devenir utilisable, je le publie donc sous une licence GLPv3 : DChars est un module pour Python3.
J'ai essayé de coller à certains principes facilitant le travail en communauté ainsi que l'écriture de code lisible : tests unitaires, code et commentaires écrits en anglais, surveillance de la qualité du code par Pylint, documentation fournie et écrite avec Sphinx.
Concrètement, je cherche d'autres personnes susceptibles d'utiliser ou d'améliorer mon module. Si vous utilisez les langues concernées, dites-moi si ce que j'ai fait vous convient ! En particulier, si certains connaissent très bien la norme ISO 15919, je suis preneur… De façon générale, n'hésitez pas à faire remonter vos remarques, je n'attends que ça, surtout si elles sont négatives !
Concrètement DChars est un module qui substitue au type str d'autres types, par exemple DStringGRC pour le grec ancien :
>>> from dchars.languages.grc.dchars import DStringGRC
>>> string = DStringGRC("μῆνιν ἄειδε θεὰ Πηληϊάδεω Ἀχιλῆος")
>>> print(string)
"μῆνιν ἄειδε θεὰ Πηληϊάδεω Ἀχιλῆος"La chaîne peut être translittérée (pour le grec ancien, j'ai implémenté trois méthodes différentes, l'une des trois étant choisie par défaut), mais il peut tout aussi bien s'agir d'un fichier entier, ce qui peut être fort pratique :
>>> string.get_transliteration()
"m/\ênin )/aeide the\a Pêlêi:/adeô )Akhil/\êos"À partir de là, il est facile d'inspecter la chaîne…
>>> string[1].tonos
"περισπωμένη"… et de la modifier en profondeur :
>>> string[1].tonos = "ὀξεῖα"
>>> print(string)
"μήνιν ἄειδε θεὰ Πηληϊάδεω Ἀχιλῆος" # notez le deuxième caractère !J'espère que mon code vous intéressera : merci à ceux qui m'auront lu !
Aller plus loin
- DChars (258 clics)
# Inverse
Posté par nojhan (site web personnel, Mastodon) . Évalué à 10.
Je ne suis pas sûr d'avoir bien compris à quoi ça servait, même si ça à l'air cool…
Est-ce que ça pourrait m'aider à faire une translitération "inverse" : d'une représentation multi-caractères latins vers de l'unicode ? (notamment vers du cunéiforme ?)
[^] # Re: Inverse
Posté par Xavier Faure (site web personnel) . Évalué à 8. Dernière modification le 23 mars 2013 à 10:27.
Bonjour nojhan,
oui, DChars a précisément été conçu pour ce genre de besoins : tu peux voir sur mon site différents exemples de translittérations dans différentes langues. Je ne connais malheureusement pas du tout le sumérien ni les autres langues utilisant le cunéiforme. Si tu es intéressé(e), peut-être pourrais-je ajouter ce système d'écriture à ceux de DChars mais me faudra alors beaucoup de détails sur l'écriture cunéiforme, des textes translittérés pour les tests, etc. Ecris-moi si tu es intéressé(e) !
Trust the Python !
# Question
Posté par psychoslave__ (site web personnel) . Évalué à 5.
C’est probablement parce que je ne connais pas le sujet, mais que signifie tonos ?
Sinon bravo pour ton travail, et merci d’en faire bénéficier la communauté.
[^] # Re: Question
Posté par gasche . Évalué à 8.
Il s'agit de savoir quel accent est placé sur les lettres. Le premier est un accent circonflexe (περισπωμένη), le deuxième un accent aigu (ὀξεῖα). Attention, le terme "périspomène" existe aussi en français (pour parler du grec, bien sûr), mais il y a une différence subtile : il désigne l'accentuation des mots qui ont un circonflexe sur la syllabe finale, ce qui n'est pas le cas ici (il s'agit de la première et avant-dernière syllable). En cas d'accent circonflexe sur l'avant-dernière (pénultième) syllabe on parle de "propérispomène".
[^] # Re: Question
Posté par Xavier Faure (site web personnel) . Évalué à 5.
La réponse de gasche est très précise, je vais simplement la compléter sur un point mineur : on peut voir que DChars privilégie souvent les noms originaux ("περισπωμένη") en lieu et place des noms plus tardifs et rattachés à telle ou telle culture ("périspomène" en français). Je gagne en précision mais je perds en lisibilité… L'exemple du latin est peut-être plus clair : vous le verrez sur mon site.
Trust the Python !
# Pyuca
Posté par GuieA_7 (site web personnel) . Évalué à 5.
Pour ceux qui sont intéressés par Unicode et Python, j'ai découvert il y a quelques temps (mais le projet date de 2006) pyuca, qui permet de trier des chaînes unicode de manière correcte, c'est à dire avec la lettre 'é' avant la lettre 'f' par exemple. J'y ai aussi contribué afin de beaucoup réduire l'empreinte mémoire (ça pourrait faire l'objet d'un journal si des linuxfriens sont intéressés).
Sinon à propos de DChars, autant je suis assez pro-GPL, autant pour des bibliothèques je trouve la LGPL plus adaptée (mais bon ce n'est que mon avis).
[^] # Re: Pyuca
Posté par Xavier Faure (site web personnel) . Évalué à 3.
Merci GuieA_7 pour ces remarques et pour le lien vers pyuca que je ne connaissais pas. Ta remarque sur la différence entre LGPL et GPL m'interpelle : peux-tu me dire pourquoi tu penches plutôt pour la première ? Merci !
Trust the Python !
[^] # Re: Pyuca
Posté par Zenitram (site web personnel) . Évalué à 7.
actuellement, tu empêches tout projet libre non GPLv3 (par exemple : GPLv2) d'utiliser ton projet. C'est très chiant de se voir imposer une licence de son code pour pouvoir utiliser une bibliothèque.
Si tu veux qu'on puisse utiliser ta bibliothèque, il vaut mieux au minimum LGPL (on doit diffuser ton code, modifié ou pas, toujours sous cette licence, mais on peut faire ce qu'on veut de notre code : MPL, BSD… Ou proprio, certes, mais ton code reste toujours libre).
Si ton but est de diffuser au maximum ton savoir, pour que n'importe qui puisse en profiter, bref diffuser, le mieux est encore une licence style BSD (une personne pourra utiliser ton code même si son code est CDDL ou autre, proprio y compris mais le but n'est-il pas de diffuser?)
Hop, allez à vos trolls GPL copyleft contre BSD vraiment libre! :)
[^] # Re: Pyuca
Posté par Xavier Faure (site web personnel) . Évalué à 3.
Merci pour ta réponse : à vrai dire je n'avais jamais imaginé opérer une distinction entre licence pour bibliothèque et licence pour un programme complet. Je vais y réfléchir : merci pour toutes ces précisions.
Trust the Python !
[^] # Re: Pyuca
Posté par Zenitram (site web personnel) . Évalué à 5.
La différence est dans les limites sur les droits des appels externes. Tu aimes le copyleft, partons dessus :
- un programme sous GPL peut être appelé par la ligne de commande non GPL, et ça va, car on appelle rarement un programme par un appel en Python direct (c'est un programme).
- une bibliothèque, au contraire, a vocation d'être appelé par du Python, et donc la GPL va imposer (si on veut utiliser ta bibliothèque, sinon ça n'imposer rien, on décide de se passer de ta bibliothèque) la licence du programme appelant. C'est pour ça qu'il vaut mieux la LGPL + GPL_linking_exception, pour retrouver dans les bibliothèques le compromis fait par la GPL sur les programmes. Imagine que pour pouvoir utiliser Linux, on demande à que toute la distribution soit GPL (ça en éliminerai du libre dans les distros) sinon c'est horrible, non la GPL ne demande pas ça, elle fait un compromis, et il faut retrouver ce compromis pour une bibliothèque (qui a vocation à être utilisée par d'autres programmes).
Bref, la GPL va bien pour les programmes, la LGPL pour les bibliothèques (d'où les "L" initial disant "Library", même si pour des raisons politiques et bien chiantes RMS l'a transformé ensuite en "Lesser"). Tu gardes le copyleft.
[^] # Re: Pyuca
Posté par GuieA_7 (site web personnel) . Évalué à 6.
Zenitram a bien résumé ma pensée, après le reste c'est un choix personnel. Il n'y a pas de bonne ou de mauvaise réponse, en revanche il y a sûrement des mauvaises solutions à des problèmes, et aussi des faux problèmes. Je m'explique.
Il n'est pas rare d'inclure plusieurs bibliothèques dans un même logiciel, ça peut donc devenir un casse tête (voire même un problème insoluble) quand lesdites bibliothèques imposent une licence au projet entier. A près la frontière entre logiciel et bibliothèque est poreuse bien évidemment (on peut prendre un bout d'un logiciel 'final' pour l'inclure dans un autre logiciel), mais il est claire qu'une bibliothèque n'a d"intérêt que si elle est est incluse par un logiciel.
À toi de voir si la peur de voir ton code inclus dans un logiciel propriétaire (mais la LGPL garantie que ton code lui reste libre [*]) dépasse ton envie de voir ton code inclus dans des logiciels libres. Après le coup de la méchante entreprise qui vient utiliser ton code génial pour faire un logiciel proprio et gagner des millions de dollarz c'est une phobie répandue, mais c'est plutôt infondé dans la réalité.
À toi de jouer :)
[*] mais comme ça a été débattu récemment ça ne garantie pas plus que la GPL une contribution upstream.
[^] # Re: Pyuca
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Merci à Zenitram et à GuieA_7 : je m'oriente en effet vers la LGPL pour les futures versions de mes bibliothèques, le programme les utilisant sera lui en GPLv3.
Trust the Python !
[^] # Re: Pyuca
Posté par Xavier Faure (site web personnel) . Évalué à 3.
Un document intéressant sur la LGPL : à titre personnel, j'hésite encore et j'attends pour me décider de bien comprendre les tenants et les aboutissants de mes choix.
Trust the Python !
[^] # Re: Pyuca
Posté par Zenitram (site web personnel) . Évalué à 3.
Cet article est écrit par des intégriste du copyleft, qui voudraient la mort du proprio à tous prix. Pas objectif du tout.
Pose-toi juste la question de savoir si tu veux faire du libre pour les intégristes de la GPLv3 (car aucun autre code sous autre licence ne peut alors utiliser ta lib), ou pour plus de monde.
"utiliser la GPL ordinaire pour une bibliothèque la rend disponible uniquement pour les programmes libres." est trompeur : c'est plutôt "uniquement pour des programmes GPLv3". Le libre? Rien à foutre, si pas GPLv3, ce n'est pas compatible, point.
Bref, le but de la diffusion de ton projet, c'est qu’on l'utilise ou pas? Ca n'a rien à voir avec le copyleft (j'ai compris que tu préfères le copyleft, je ne parle donc plus de licence non copyleft). Remet toi l'exemple des distros : pour toi, une distro ne devrait être diffusable que si tout est GPLv3? (interdiction de code CDDL? Interdiction de code GPLv2? ou autre non compatible GPLv3? de drivers proprio?). Prend alors GPLv3 pour ta lib, mais bon, il y a des chances que quasi-personne ne l'utilise. Sinon c'est la LGPL (v3 si tu ne veux pas de Tivoïsation mais tu perds aussi pas mal de monde qui la déteste et préfère la v2).
[^] # Re: Pyuca
Posté par ariasuni . Évalué à 2.
Sans vouloir être hors-sujet, pourquoi certaines personnes n’aiment pas la GPLv2? Je sais qu’elle apporte des avantages, mais je ne connais pas les inconvénients.
Écrit en Bépo selon l’orthographe de 1990
[^] # Re: Pyuca
Posté par Zenitram (site web personnel) . Évalué à 3.
correction : c'est la v3 qu'ils n'aiment pas.
Pourquoi? interdiction de tivoïsation (donc ça empêche d'être intégré à certaines solutions dont le logiciel est sans problème libre mais dont on ne peut laisser une version modifiée pour des raisons de législation, genre modifier les fréquences Wifi ou GSM, ou permettre de virer les DRM de la chaîne de TV) + insécurité juridique due à la complexité de la v3 (la v2 aussi est complexe mais est déjà allée devant quelques tribunaux, on sait un peu plus à quoi s'en tenir).
Perso, j'ai fait LGPLv3 pendant quelques temps, mais suite à discussion avec des clients potentiels, repassé à LGPLv2 car j'ai vu que la v3 ne m'apporte pas grand chose de plus (j'ai toujours les modifs si j'achète le produit) et les clients sont contents (ça passe avec leur département juridique) et c'était plutôt pour "suivre le mouvement", et en fait je me suis rendu compte que finalement je m'en fous des modifs perdues à droite à gauche, j'évolue vis à vis du ma vision du libre, je vais simplifier encore plus pour filer encore plus de libertés (BSD 2-clauses), na.
[^] # Re: Pyuca
Posté par MrLapinot (site web personnel) . Évalué à 6.
Je serais intéressé que tu en fasses un journal (sérieusement). Je me souviens de tes argumentaires réguliers sur ton choix de la GPL, les avantages dans le cadre de ton boulot, etc. et je serais curieux d’en savoir plus sur les raisons de cette évolution.
(Personnellement, tous mes logiciels sont en BSD, mais je travaille en milieu académique donc les enjeux ne sont pas les mêmes.)
[^] # Re: Pyuca
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Comme MrLapinot ça m'intéresserait d'avoir un journal sur le sujet. Si Zenitram (ou un autre) pouvait parler de son expérience sur la question des licences, cela contribuerait à éclairer ma lanterne.
Trust the Python !
[^] # Re: Pyuca
Posté par Zenitram (site web personnel) . Évalué à 5.
Voila
[^] # Re: Pyuca
Posté par MrLapinot (site web personnel) . Évalué à 3.
Merci :-)
# commentaires
Posté par Antoine . Évalué à 5.
Juste deux modestes commentaires :
pour ce genre d'application, l'usage serait plutôt de fournir une API fonctionnelle que de créer une classe distincte de la classe str (bien qu'apparemment PyICU fournisse aussi une classe distincte)
une bibliothèque sous licence GPL limite fortement ses possibilités d'utilisation, surtout dans la communauté Python où les licences non-copyleft sont largement préférées
Bonne chance :-)
[^] # Re: commentaires
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Bonjour Antoine, merci de ton commentaire : peux-tu me donner un exemple de module (Python) donnant "une API fonctionnelle" pour que je comprenne l'avantage par rapport à la méthode que je suis ? Merci !
Quant à ta remarque sur la licence, c'est un vrai problème pour moi : GuieA_7 m'a parlé ci-dessus de la LGPL et j'attends ses arguments pour trancher. De façon générale, ma conception du libre correspond bien à ce que proposent les licences GPL mais je sais que je me prive ainsi d'une grande partie des utilisateurs potentiels.
Trust the Python !
[^] # Re: commentaires
Posté par Aluminium95 . Évalué à 1. Dernière modification le 23 mars 2013 à 20:53.
Un avantage serait de ne pas avoir une classe, et donc d'être compatible avec le type
strde python sans se poser de questions.[^] # Re: commentaires
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Je plussoie à la remarque d'Aluminium95 mais je demande de l'aide pour comprendre comment le faire. Un bout de code pour m'aider à imaginer l'interfaçage avec mes classes ? Ou le nom d'une bibliothèque correspondant à la solution proposée par Aluminium95 et celle d'Antoine ? Merci de m'aider !
Trust the Python !
[^] # Re: commentaires
Posté par benoar . Évalué à 3.
Je ne suis pas sûr de comprendre tous tes besoins, mais pour moi ta librairie ressemblerait plutôt à un “codec” au sens python du terme : http://docs.python.org/2/library/codecs
Ainsi, on pourrait utiliser
encode()/decode()sur n'importe quellestr.[^] # Re: commentaires
Posté par Xavier Faure (site web personnel) . Évalué à 1.
C'est une bonne idée à laquelle je n'avais jamais songé. Merci !
Trust the Python !
# corrections
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Si un modérateur pouvait remplacer dans la dépêche "Phoseg" par "DChars" et renommer le lien "Dchars" en "DChars"… Merci d'avance !
Trust the Python !
[^] # Re: corrections
Posté par patrick_g (site web personnel) . Évalué à 3.
C'est fait.
[^] # Re: corrections
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Merci.
Trust the Python !
# pour le tibétain...
Posté par chonyi . Évalué à 5.
Juste une suggestion : c'est possible également de gérer la translittération EWTS (plus acceptable niveau informatique que le Wylie original) du tibétain.
J'ai fait une bibliothèque (pas vraiment finie, mais le code fonctionne…) pour transformer de l'EWTS en Unicode, c'est relativement simple (mais ça utilise flex, je ne sais pas si c'est facilement transposable en python…), mais pour Unicode -> EWTS, ça va pour les cas simples, mais il y a beaucoup de cas où, si la voyelle n'est pas marquée (c'est à dire que c'est le son a), il est très difficile de savoir sur quelle consonne elle se situe, exemple : གདག་ il est difficile de savoir s'il s'agit de gadg ou gdag… il y a bien des règles mais, comme d'habitude, beaucoup d'exceptions… Je n'ai malheureusement pas le temps (ni l'utilité pour l'instant) de coder quelque chose dans ce sens, mais ça a déjà été fait en perl et java sur le site du THDL, il doit être possible de convertir ça en python…
Si tu as besoin d'aide je peux donner des conseils en tous cas.
[^] # Re: pour le tibétain...
Posté par Xavier Faure (site web personnel) . Évalué à 5.
Merci chonyi pour ton message : je reconnais dans le problème dont tu parles quelque chose qui ressemble un peu à un souci que j'ai pu rencontrer avec la devanāgarī, heureusement bien plus précise. Dans la mesure où je ne connais absolument pas le tibétain et son système d'écriture (bien qu'apparenté à la devanāgarī) je ne peux me lancer dans l'écriture d'un module spécifique à cette langue. C'est dommage, car finalement il ne me "faudrait que" trois choses : un interlocuteur ayant un peu de temps, une norme strictement décrite et une batterie de tests tout préparés. S'il y a des volontaires, je suis des vôtres pour étendre DChars !
Trust the Python !
[^] # Re: pour le tibétain...
Posté par chonyi . Évalué à 5.
Pour répondre à tes trois points:
Personnellement j'ai un peu de temps. Il y a également des gens qui travaillent beaucoup sur les choses du tibétain, on retrouve les mêmes noms un peu partout, ils travaillent notamment avec le gouvernement du Bhoutan.
Pour la norme précise, j'ai eu personnellement du mal à faire la conversion EWTS->Unicode justement car la norme était très peu précise (principalement sur les inputs non-prévus). En discutant avec les personnes qui l'ont faite, on a réussi à se mettre d'accord sur quelquechose de plus précis, mais ça reste relativement flou. Pour le côté Unicode -> EWTS c'est heureusement un peu plus strict (mis à part les difficultés que j'ai exposées dans mon message précédent). Il y a un ensemble de règles ici : http://www.thlib.org/reference/transliteration/#!essay=/thl/ewts/rules/ et dans les liens du menu de droite. Pour la difficulté du placement de la voyelle quand elle n'est pas indiquée, je dois pouvoir trouver quelquechose… Si ça t'intéresse je te tiens au courant. Dans tous les cas il n'existe pas de norme vraiment précise type ISO.
Pour la batterie de tests, je peux en écrire quelques-uns sans trop de problème, mais ce ne sera pas forcément exhaustif…
Une autre remarque : quelquechose d'assez difficile est de convertir les mantras, car c'est en fait du sanskrit translittéré en tibétain, avec des lettres et des combinaisons qui n'existent pas en tibétain standard, pour pouvoir écrire des prononciations sanskrites. Faire la translittération en EWTS a un intérêt mais finalement assez limité, par contre il serait intéressant de pouvoir les transformer en en devanagari (soit unicode, soit translittéré). Ça donnerait même un intérêt assez fort à DChars, car c'est quelquechose de très utile (notamment pour pouvoir traduire les mantras)… Cet aspect-là pourrait motiver des personnes à aider… Bon évidemment la limite c'est les mantras linguistiquement assez improbables qui mélangent tibétain et sanskrit, voire qui ne sont carrément ni l'un ni l'autre (certains sont en d'autres langues)…
[^] # Re: pour le tibétain...
Posté par Xavier Faure (site web personnel) . Évalué à 2.
Ce que tu écris m'intéresse beaucoup et je vois poindre deux projets : (1) DChars qui s'occuperait de la conversion stricte EWTS<->écriture tibétaine (2) un programme utilisant DChars pour passer de l'écriture tibétaine des mantras à la devanāgarī "d'origine" (si j'ai bien compris).
Des deux projets, le plus excitant est bien sûr le second mais il faudra[it] d'abord en passer par le premier. Pourquoi ne pas poursuivre la discussion par mail (suizokukan A_T orange DOT fr) ?
Trust the Python !
# Graphies allégées
Posté par Al . Évalué à 5.
Je suis enthousiasmé par ton projet, et je vois une utilisation simple : à partir du moment où les symboles unicode sont analysés, il doit y avoir moyen d'écrire des méthodes toutes bêtes pour simplifier les graphies. Par exemple, si on translittère du sanskrit, en confondant les voyelles courtes et longues [1], on peut produire de manière automatique une translittération certes approximative mais relativement élégante et 100% ASCII.
Même sans utiliser des translittérations vers l'alphabet latin, on peut faire le même genre de transformation pour l'hébreu : en éliminant les voyelles et les daghesh/mappiq, on obtient de l'unicode qui passe bien sur des plateformes qui n'ont pas été configurées et qui ne disposent pas des polices qui vont bien. Même chose en supprimant l'accentuation du grec etc.
Je n'ai pas encore essayé les transformations que je viens de mentionner, mais ta bibliothèques a l'air très commode pour ça.
[1] Bien entendu, ce n'est pas la seule chose à simplifier
[^] # Re: Graphies allégées
Posté par Xavier Faure (site web personnel) . Évalué à 3.
Merci Alexandre pour tes encouragements; l'idée de présenter une version allégée des translittérations m'est venue à plusieurs reprises à l'esprit et de fait, si tu es intéressé, je peux l'intégrer rapidement à DChars. N'hésite pas à me contacter par mail pour plus d'informations (suizokukan A_T orange DOT fr).
Trust the Python !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.