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. Regards, Christian _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
