[CSProjects] The case for Python

[Vlad Dogaru]

Salut,

m-am uitat peste implementarea ODF in Python (Odfpy)[1] si am vazut ca e 
foarte aproape de structura XML a documentelor (care e uneori mai putin 
intuitiva decat ne-am astepta). Nu stiu daca asta e bine sau nu; voi ce 
credeti?

As a sidenote, am si experimentat cu treaba asta (adica am copiat 
exemplul lor de spreadsheet :-P) si arata chiar bine. Nu e in intregime 
valid (si validatorul e tot al lor[2]), dar stiu ca m-am lovit si eu de 
asta cand le scriam manual si ar putea fi validatorul imperfect. 
Important e ca se vede in OOo si apare ce trebuie. Documentul rezultat 
poate fi editat fara probleme.

O sa fi lung mail-ul, dar trebuie inclus si asta: biblioteca in sine e 
licentiata LGPL (scrie in antetul fisierelor, chiar daca nu exista 
COPYING). Asta e o problema daca ne legam de ea cu proiectul nostru BSD? 
I should think not, dar daca stie cineva mai bine, sa fie clar din capul 
locului. Buba e ca sunt o gramada de locuri unde poti intreba de 
software, dar nu am gasit niciunul referitor la licente si alte lucruri 
din astea neimportante IMO.

Acum, the real case for Python: e mult mai incet decat C, comparabil cu 
Ruby, Perl, PHP la viteza, dar oricum generarea unui spreadsheet din 
asta nu e chiar mission critical. Si ma indoiesc ca ar dura mai mult de 
cateva fractiuni de secunda oricum.

Manipulare de siruri de caractere (pentru settings.conf) -- check
Manipulare de date si ore (nu am lucrat cu ele, dar arata bine) -- check
Mod de operare interactiv (REPL-like) -- check
Gaining usage on a corporate scale (NASA & Google come to mind) -- check

Stiu, asta nu convinge pentru ca sunt caracteristici comune ale 
limbajelor de genul asta (poate cu exceptia ultimei, care oricum e mai 
mult sugar :-P). Ceea ce sper sa impresioneze e The Zen of Python (e 
easter egg -- porniti Python si scrieti ``import this''):

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Awaiting thoughts,

Vlad

[1] http://www.opendocumentfellowship.org/projects/odfpy
[2] http://opendocumentfellowship.org/validator
-- 
/* no comment */