Reporting system and potentially Python

[John Ralls]

On Jul 7, 2011, at 4:24 PM, Christian Stimming wrote:

> Am Donnerstag, 7. Juli 2011 schrieb John Ralls:
>>>> So I am OK with needing to get more familiar with something
>>>> such as Python, C, or Java to do the work, but I don't want to get knee
>>>> deep in a major feature patch to find out something else is preferred.
>>> 
>>> If you are able to insert some python code that will display some report,
>>> I will fully agree this to be a worthwhile goal and I will happily apply
>>> your patches to SVN trunk.
>> 
>> Christian: Please don't accept Python code into Gnucash. Python has
>> version-to-version compatibility problems, and I've found with pure-python
>> applications like Gramps that it requires bundling a Python interpreter
>> with the application so that everyone gets the same version.
> 
> You do realize that gnucash already comes with a lot of python code for quite 
> some time being, don't you? Namely we already have the python wrappers for the 
> core engine object being generated by SWIG for approx. 2-3 years by now. More 
> recently, there has been an optional python module added so that the framework 
> is already there to do some real new features with that. 
> 
> To me, issues with version incompatibilities in python are indeed a drawback 
> of that language, but all languages have drawbacks and advantages. The clear 
> advantages to allow python code in gnucash is that
> * the python wrappers for all engine objects are already there, so using them 
> is a rather efficient way of using your time to implement something new
> * the python language is significantly more easy to learn and suits the 
> "normal programmer's thinking" much better than other languages
> 
> As for JavaScript, you have the disadvantage that we (so far) don't have 
> wrappers for all of our engine objects, so this is a very boring task that 
> needs to be begun and somewhat completed first. Also, the JavaScript language 
> is significantly difficult to work with in a serious way. It's much more like 
> Scheme than one would initially expect, and it suffers the same problem than 
> Scheme: Only a smaller set of programmers really understand the concepts 
> behind it well enough to create good architectures in that language.
> 
> With this being said, we had Tim's question here: "I'd like to improve 
> something with the reports; which language should I use." With the above 
> advantages and disadvantages, I still think the most efficient way for Tim to 
> spend his time is creating a report in python. And yes, I still think I will 
> happily add related python code into the optional src/python/ module, even 
> though we know about the limitations of python w.r.t. version issues. But we 
> also know about its benefits. My cost-benefit comparison so far still turns 
> out python as the suggested way to proceed for now.

There's a big difference between a toy Python console for hackers and reports at the core of user interaction with Gnucash. Like src/gnc, src/optional.gtkmm, and src/cmakefilemodules, src/optional/python isn't appropriate to include in a general-distrbution binary. The standard reports *must* be included in such a binary. 

You're right, though, that Javascript is a non-starter. I hadn't adequately investigated what it would take to access the data from javascript. (Details in my reply to Phil.)

I think Tim is looking for something different than you think, but I'll let him speak for himself.

Regards,
John Ralls