Sympathie belge
Denis
spirou at carolo.net
Mon Nov 5 03:29:03 CET 2001
Bonjour tous,
J'ai aterri sur votre page ce soir et je viens de lire presque
toutes les archives de la liste. Je suis très intéressé par le
sujet, ayant moi-même moultes fois souhaité disposer de ce
genre d'outil sous Linux.
J'ai installé voilà déjà quelques mois (et assez vite oublié)
l'un ou l'autre logiciel du genre GNU-Cash, qui, ceci dit en
passant, a des caractéristiques intéressantes.
Chaque fois, je suis déçu : le logiciel est bogué, ou encore
trop sommairement développé, ou non adapté à mon utilisation
immédiate et pour l'adapter, je devrais me lancer dans l'étude
d'un code que je comprends parfois à peine, alors a fortiori,
pour le modifier ... !
Je nourris donc un souhait très particulier : voir un logiciel
se développer en Python.
Vous le savez, Python est un langage d'une souplesse
exceptionnelle et le code Python est presqu'obligatoirement
limpide. On a parlé de portabilité dans les messages
précédents ; Python tourne sur presque tous les O.S. existants.
On a parlé d'interface Web, on peut envisager utiliser Zope ;
on a parlé d'interface non-Web, on peut utiliser WxPython.
Et ainsi de suite, j'ai des tonnes d'arguments, vous le pensez
bien en regardant la signature ci-dessous :-)
Un bon programmeur C ou C++ peut se mettre à Python en un mois
à peine. Python peut être intégré dans une application C ou C++
tout comme il peut utiliser des librairies C et C++ (WxPython,
justement, en est un bon exemple). Si la rapidité de traitement
devait être primordiale, rien n'empêche de recoder les
fonctions les plus pénalisantes en C par après.
En attendant, le confort est tellement supérieur !
Enfin, voilà, que ce soit du Python ou non, il me semble
primordial de travailler façon objet (OO) malgré tout.
J'ai lu le thread sur le choix de la base de données : pour
moi, j'aime beaucoup PostgreSQL, mais il serait sans doute bon
de prévoir une petite classe de façade afin de pouvoir cacher
le stockage de données. Supposons que l'un souhaite intégrer
des données existant dans une autre base, que l'autre ne jure
que par le XML, et ainsi de suite ... Si on définit de belles
methodes à un Rack abstrait, et que l'on s'efforce de dériver
la classe réelle de celle-là, on peut remplacer un stockage de
données par un autre sans mettre toute l'application en péril.
Idem pour les interfaces, évidemment. Les amateurs d'UML,
quelque soit le langage d'implémentation utilisé, ne pourront
qu'être d'accord.
Bon, j'arrête là, je crains d'être long pour une prise de
contact. Autant attendre vos premiers avis avant d'aller plus
loin :-) Mon mail aura sans doute le mérite de relancer la
discussion.
A noter que des échanges belgo-suisses francophones pourraient
peut-être faire l'objet de subsidiations par l'Agence de la
Francophonie, surtout si d'autres pays francophones sont aussi
représentés.
A bientôt. Amitiés de Charleroi.
--
Denis FRERE
P3B : Club Python(-Zope) Belge --------- http://www.p3b.org
OS3B : Club Open-Software(-Linux) Carolo http://www.os3b.org
Aragne : Python-Zope Solutions & Formations http://www.aragne.com
More information about the compta
mailing list