On Jan 13, 2014, at 9:03 AM, Geert Janssens <janssens-ge...@telenet.be> wrote:
> 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. We're in complete agreement, including about getting Guile out of the middle of GnuCash. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
