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