On Sunday 12 January 2014 20:14:11 John Ralls wrote: > On Jan 12, 2014, at 11:22 AM, Henning Jacobs <henn...@jacobs1.de> wrote: > > IMHO the Python bindings are a really great way of enhancing the > > GnuCash functionality without having to code C/C++ (I would not be > > very productive with it...) > > Unfortunately Python isn't a very good built-in scripting language, > and supporting it on Mac and Windows is a serious PITA. Guile is > better, except the number of Scheme programmers loose in the world is > pretty small. For the foreseeable future I'd expect that any code > accepted into GnuCash itself will have to be C/C++ or Scheme, with a > very strong preference for C++. > My long term vision goes even further: I would like to bring the current scheme dependency down to becoming optional at some point. The core functionality should not depend on guile nor python. But both languages can be used to extend the core functionality. All data structures that are currently maintained in guile (like the options for example) should be implemented in C/C++ IMO.
I'm aware this is a bold claim, particularly given the current report system is mostly written in guile. But in a wider scope the report system could be considered optional in itself. None of the report options are stored in the gnucash data file. It's saved in separate meta files. It's mostly a gui-only extension of gnucash. > > I will properly write more code in the near future using the Python > > bindings --- I would also gladly help extending/improving the > > current > > code base and/or documentation :-) > > Rather than extending the current wrappers, I think we need to work > out a reasonable public API that properly hides the implementation. > The current policy of "open kimono" would be a serious constraint on > further development if there was a bunch of external code that we had > to be worried about not breaking. The way some of the code flips back > and forth between C and Scheme is pretty bad already. > This flipping back and forth is part of what I want to get rid of. So I'm all for a reasonable public API. Geert _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
