Reporting system and potentially Python
phil.longstaff at yahoo.ca
Thu Jul 7 17:06:46 EDT 2011
From: Christian Stimming <christian at cstimming.de>
To: John Ralls <jralls at ceridwen.us>; Tim M <tim at filmchicago.org>
Cc: gnucash-devel at gnucash.org
Sent: Thursday, July 7, 2011 4:24:10 PM
Subject: Re: Reporting system and potentially Python
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
wrappers for all of our engine objects, so this is a very boring task that
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.
gnucash-devel mailing list
gnucash-devel at gnucash.org
More information about the gnucash-devel