Re: Python bindings: patch, documentation, examples
On 05/09/2014 06:37 PM, David Osguthorpe wrote: On Thu, May 08, 2014 at 11:47:34PM -0700, mshapiro wrote: David Osguthorpe wrote I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) Can you post what libraries you used, where you got them, how to use them and your prototype.scm file. Also, any pointers to useful documentation for using the Python bindings would be greatly appreciated. I am primarily interested (at the moment) in accessing budgeting information and future transactions, as well as accounts, since I would like to do more forecasting than the standard reports provide. it is really hacky - and I still had crashes when attempting to create real reports so its very, very alpha but if you wish to pursue it here are the details I have the feeling that I will be better off to just write a standalone python script. This is not really a problem. A program to do forecasting can be done outside gnucash just fine. Except that I still need to find a way to access the future transactions and the budget information. I haven't seen either of these in any of the example reports for the python bindings. Does anyone know of any info on how to use the python bindings to access these? note this does not use any of the python bindings - as far as I can tell they only work for non-gui standalone scripts - well its the only Ive used them - you would write a script to access your gnucash database (xml or SQL) and use any python modules to format the data for a new report completely outside of gnucash for the moment I would say you would be better just writing command line scripts using the python bindings to generate HTML or whatever reports here are some details 1. you need pyguile - a module for calling guile version of scheme from python - unfortunately the available source has not been udpated for years so needed quite a bit of patching to build (I run under macports on OSX mainly) - one patch I did have to add was the ability to return so called SCM (scheme) objects back to guile 2. you need schemepy - which has a module for calling python from guile version of scheme - again the available source has not been udpated for years so needed some patching to get running Then you have the prototype.scm (simply not bothered to change name) which sets up to call python where you could write your report. My initial goal was to write reports in python - Im primarily writing in this now and although I had tried scheme for a multiple stock price scatter plot report every time I went back trying to re-think in scheme was a pain I tried to write my report in scheme, and I can't really say that I failed. Just that I never got it finished. I took the Balance Sheet , the Budget Report and the Future Transactions Report and tried to put them together. I was able to successfully combine all of the required options so that they can be input on a singe screen. Then it simply runs the Balance Sheet. If I could figure out how to access the future transactions and budgeting data and update the accounts on the Balance Sheet before displaying them then I would be all set. But, so far, I have not been able to wrap my head around that much scheme. As a co-worker says of LISP (he uses it in AutoCad) I find myself Lost In Stupid Parenthesis. It makes my head hurt. The major problem I ran across is that when analysing the GUI report system in gnucash I discovered it was not done in pure gtk but some of the gui is actually written in scheme by calling gtk gunctions via swig wrapped functions involving gtk - to directly call python reports would need re-writing most of this GUI scheme stuff using the python gtk library - not difficult but seemed like a lot of work I had hoped to find a report function where I could plugin in a call to python so could then do the report in python (python has the ctypes module which allows calling C functions in arbitrary C shared libraries such as gnucash uses) - pygtk allows direct use of gtk functions in python I did this around 2.4.7 and am looking to review it now at 2.6.3 from that analysis as far as I could tell the final report result is an html text string which is written to a file - again these components using scheme coding If you really want the files let me know Yes. If you can post the files, or links to them, then I will have them if I decide to try and go down that route. If not, well, it won't hurt to have them and maybe it can help someone else. as you have discovered there isnt much documentation of the python bindings Yes. If I had proper documentation then I would have just written the standalone report and been done with it. As it stands, I have no actual proof that the bindings will give me access to the budgeting and future transactions. That may never have been
Re: Python bindings: patch, documentation, examples
David Osguthorpe wrote I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) Can you post what libraries you used, where you got them, how to use them and your prototype.scm file. Also, any pointers to useful documentation for using the Python bindings would be greatly appreciated. I am primarily interested (at the moment) in accessing budgeting information and future transactions, as well as accounts, since I would like to do more forecasting than the standard reports provide. Marc -- View this message in context: http://gnucash.1415818.n4.nabble.com/Python-bindings-patch-documentation-examples-tp4667098p4670696.html Sent from the GnuCash - Dev mailing list archive at Nabble.com. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Thu, May 08, 2014 at 11:47:34PM -0700, mshapiro wrote: David Osguthorpe wrote I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) Can you post what libraries you used, where you got them, how to use them and your prototype.scm file. Also, any pointers to useful documentation for using the Python bindings would be greatly appreciated. I am primarily interested (at the moment) in accessing budgeting information and future transactions, as well as accounts, since I would like to do more forecasting than the standard reports provide. it is really hacky - and I still had crashes when attempting to create real reports so its very, very alpha but if you wish to pursue it here are the details note this does not use any of the python bindings - as far as I can tell they only work for non-gui standalone scripts - well its the only Ive used them - you would write a script to access your gnucash database (xml or SQL) and use any python modules to format the data for a new report completely outside of gnucash for the moment I would say you would be better just writing command line scripts using the python bindings to generate HTML or whatever reports here are some details 1. you need pyguile - a module for calling guile version of scheme from python - unfortunately the available source has not been udpated for years so needed quite a bit of patching to build (I run under macports on OSX mainly) - one patch I did have to add was the ability to return so called SCM (scheme) objects back to guile 2. you need schemepy - which has a module for calling python from guile version of scheme - again the available source has not been udpated for years so needed some patching to get running Then you have the prototype.scm (simply not bothered to change name) which sets up to call python where you could write your report. My initial goal was to write reports in python - Im primarily writing in this now and although I had tried scheme for a multiple stock price scatter plot report every time I went back trying to re-think in scheme was a pain The major problem I ran across is that when analysing the GUI report system in gnucash I discovered it was not done in pure gtk but some of the gui is actually written in scheme by calling gtk gunctions via swig wrapped functions involving gtk - to directly call python reports would need re-writing most of this GUI scheme stuff using the python gtk library - not difficult but seemed like a lot of work I had hoped to find a report function where I could plugin in a call to python so could then do the report in python (python has the ctypes module which allows calling C functions in arbitrary C shared libraries such as gnucash uses) - pygtk allows direct use of gtk functions in python I did this around 2.4.7 and am looking to review it now at 2.6.3 from that analysis as far as I could tell the final report result is an html text string which is written to a file - again these components using scheme coding If you really want the files let me know as you have discovered there isnt much documentation of the python bindings I have some scripts and gnucash binding extensions - Ive been updating them because of the changes between 2.4 and 2.6 - I tend to use lots of comments to document what I discover as I use the bindings - youre welcome to them as well (I also have some updates to the swig bindings which my extensions/script use which I have not posted as patches because still figuring the changes from 2.4 to 2.6) David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
Am 12.01.2014 20:22, schrieb Henning Jacobs: Hi, I recently discovered the great Python bindings and just updated http://wiki.gnucash.org/wiki/Python_Bindings to contain pointers to my scripts. Now my questions: * GncPrice does not contain a proper __init__, therefore I monkey patched it: https://github.com/hjacobs/gnucash-stock-portfolio/blob/master/gnucash_patch.py --- What's the best way to make a patch request for the original GnuCash Python bindings? * Are there any other known/major users of the Python bindings? I use them on a regular basis to import my onlinebanking data. regards, Christoph Holtermann * Who is maintaining the Python bindings and is there any roadmap to improve them? 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...) 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 :-) - Henning ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- --- Nachricht gesendet von C. Holtermann --- - - - Verschlüsselte Nachrichten können über - - den öffentlichen Schlüssel auf folgendem - - Keyserver an mich gesendet werden: - http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x4DD9CF0482B0620B ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Tuesday 14 January 2014 21:53:40 Henning Jacobs wrote: Hi, thanks for all the answers and insights I got from your mails --- what I got out of it: * Sadly no core developer seems to be using the Python bindings :-( Actually I am using the python bindings to synchronize data in gnucash with a legacy inventory application based on postgres. But due to my limited python knowledge this is only a very simple script and not very pythonic if you will. So using: yes, actively developing: no. * There are some guys actively using it for their needs. * Python seems to bring compatibility issues for Win/Mac (personally I'm more and more getting an Open Source Nazi, but I'm sure Win/Mac should be no problem if someone invests time) I tend to agree with this statement. I can't speak for the mac side of things, but on Windows it probably just boils down to providing an easy interface to install a python version that is compatible with mingw. Ideally this could be an optional component in the (ISS) installer (and while we're at it, we could move the optional perl installation in there as well). Optional in this case would mean that it is *not* included in the installer itself but downloaded separately if the user selects it in the installer. * Core C/C++ API will mostly stay stable, so Python bindings will/should be maintainable for the future See John's reply as well. If you want to help improve the python bindings you'll likely have to follow the development of core gnucash closely in this development cycle as it will change a lot indeed. But you don't have to carry the burden alone. As I stated before gnucash is a community effort. I don't consider anybody responsible to fix each bindings breakage. You are of course invited to send in patches to fix breakage but even only reporting changes that break the bindings is also a good contribution already. That can inspire someone else to give it some attention if you can't. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
John Ralls jra...@ceridwen.us writes: You should use the Query interface to find objects. If there are any “foo_find_by_bar” functions in the API now, they’ll be ripped out in the rewrite. In order to get to multiuser we’ll only be instantiating objects on demand, ideally only to edit unless it turns out to be easier to instantiate for viewing. Or if not ripped out they may be modified to use the Query interface.. Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Mon, Jan 13, 2014 at 03:59:29PM -0800, John Ralls wrote: Please remember to copy the list on all replies. Use “reply all” or, if your mailer supports it, “reply list”. sorry - on some lists the list email is first - others not - remembering which one is which is a problem You should use the Query interface to find objects. If there are any “foo_find_by_bar” functions in the API now, they’ll be ripped out in the rewrite. In order to get to multiuser we’ll only be instantiating objects on demand, ideally only to edit unless it turns out to be easier to instantiate for viewing. what is the Query interface - is that the libqof functions?? Is there an example which shows how this is done - I dont remember seeing any query functions for budgets in gnc-budget.c David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
David Osguthorpe david.osgutho...@gmail.com writes: what is the Query interface - is that the libqof functions?? yes, see qofquery.h Is there an example which shows how this is done - I dont remember seeing any query functions for budgets in gnc-budget.c They wouldn't be there. QofQuery is a generic framework used for everything. But much of GnuCash doesn't use it because it has always loaded all data from the data store into RAM and then used that cache. For multi-user support it cannot do that anymore and all uses must change to use the Query interface to pull from the database. David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Jan 14, 2014, at 8:05 AM, David Osguthorpe david.osgutho...@gmail.com wrote: On Mon, Jan 13, 2014 at 03:59:29PM -0800, John Ralls wrote: Please remember to copy the list on all replies. Use “reply all” or, if your mailer supports it, “reply list”. sorry - on some lists the list email is first - others not - remembering which one is which is a problem You should use the Query interface to find objects. If there are any “foo_find_by_bar” functions in the API now, they’ll be ripped out in the rewrite. In order to get to multiuser we’ll only be instantiating objects on demand, ideally only to edit unless it turns out to be easier to instantiate for viewing. what is the Query interface - is that the libqof functions?? Is there an example which shows how this is done - I dont remember seeing any query functions for budgets in gnc-budget.c The current interface is QOFQuery. All of the persistent objects in Engine implement the QOFObject interface which QOFQuery uses, so it's available for Budgets regardless of whether the gnc-budget code uses it. You must *not* look at code in src/engine for examples of what to do: That code is private and is going to change a *lot* in the coming dev cycle. Look instead at src/report. I can't be certain that we'll get to replacing QOFQuery in this cycle, but we will eventually replace it with SQL when we migrate to using the database as a database instead of a mere persistence store, so be sure to abstract your query code so that it can be easily replaced. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, thanks for all the answers and insights I got from your mails --- what I got out of it: * Sadly no core developer seems to be using the Python bindings :-( * There are some guys actively using it for their needs. * Python seems to bring compatibility issues for Win/Mac (personally I'm more and more getting an Open Source Nazi, but I'm sure Win/Mac should be no problem if someone invests time) * Core C/C++ API will mostly stay stable, so Python bindings will/should be maintainable for the future I hope to at least gather/contact the people interested in Python bindings and bring it forward :-) Let's see how much spare time I have next weekend... - - Henning Am 14.01.2014 07:25, schrieb Tom Lofts: Hi Henning, * Are there any other known/major users of the Python bindings? * Who is maintaining the Python bindings and is there any roadmap to improve them? While not a major user of the Python bindings I've contributed a few minor fixes and enhancements so far which are visiable in recent commits at https://github.com/Gnucash/gnucash/tree/trunk/src/optional/python-bindings Primarily, I've been looking to create a REST API for Gnucash using the Python bindings in order to provide a standard way of interfacing with Gnucash across various languages. My initial development is at https://github.com/Gnucash/gnucash/tree/trunk/src/optional/python-bindings/example_scripts/rest-api and I have some additional improvements I'm working on at the moment which isn't ready for public release, but I'd be happy to share with you if you wish. I'm focusing primarily on providing access to the business functions (creating and editing customers and, creating, editing, posting and paying invoices) as these are the areas I use most but this should also cover working with transactions and splits. If you have any queries about my development please let me know or feel free to email me directly if you don't think it would benefit including the list. Kind regards, Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLVo84ACgkQCI3KHACjjwVH6wCfUhAjB/kXmo4LlYaa5X4P46FC wU4AoIzpMA6p+xmvU+ps1DUO32q3gGB/ =NR2p -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Jan 14, 2014, at 12:53 PM, Henning Jacobs henn...@jacobs1.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, thanks for all the answers and insights I got from your mails --- what I got out of it: [SNIP] * Core C/C++ API will mostly stay stable, so Python bindings will/should be maintainable for the future Absolutely not. The core C API is going to change a lot this dev cycle. A lot of it is going to become C++, and in the process a lot of what’s now public won’t be. There will be Python and Scheme bindings to what remains public, but they won’t look like what they do now. Sorry for the pain, but the current API exposes a lot of internals that have to change in order to get to multi-user and to make changing GUI frameworks feasible. The future API will hide those details and allow for it to be stable in the face of changing internals. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
I am using the python bindings - in fact was just going to see about getting some patches to update the bindings. Just updated to 2.6.0 - looks as though some functions that used to exist no longer exist in the Account class so need to be removed from gnucash_business.py Ive noticed that the python bindings are not very pythonic - I have some updates which improve this eg account lookup used to require testing that the swig instance was None - this got updated somewhere between 2.4 and 2.6 so now the python class returns None - the pythonic way seems to me is to raise exception - which is what one of my updates does So I was going to email this list to see what is going on with the bindings and how such improvements could be added. Such updates will fail existing python code - such as the examples - although Ive found other cases where existing changes means some of the example python code no longer works David On Sun, Jan 12, 2014 at 11:22 AM, Henning Jacobs henn...@jacobs1.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I recently discovered the great Python bindings and just updated http://wiki.gnucash.org/wiki/Python_Bindings to contain pointers to my scripts. Now my questions: * GncPrice does not contain a proper __init__, therefore I monkey patched it: https://github.com/hjacobs/gnucash-stock-portfolio/blob/master/gnucash_patch.py --- What's the best way to make a patch request for the original GnuCash Python bindings? * Are there any other known/major users of the Python bindings? * Who is maintaining the Python bindings and is there any roadmap to improve them? 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...) 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 :-) - - Henning -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLS63oACgkQCI3KHACjjwXHsACdGvhhYVASKEK13bw1cbRAM/8v MBAAmwfus1dYcRk4zvU+KzJ20T8YcdWi =snST -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Sun, Jan 12, 2014 at 08:14:11PM -0800, John Ralls wrote: * Who is maintaining the Python bindings and is there any roadmap to improve them? They're maintained enough to keep them compiling by the core team. They're not really part of our development plan, they're mostly just there. This is not good news to me - Ive been playing with these for my personal accounting eg updating stock prices, currencies - to take into account the vagaries of finance-quote failing in various ways - and unable to do currency histories - so can do a bulk update of prices every so often 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++. I dont understand why you would say this - Im using a lot of code with python (and Im on a Mac mainly also Linux - use gnucash via macports) in a lot of very different code systems eg pymol, ffmpeg) I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) - was trying to look at ways to write reports in python pygtk gives access to gtk functions (and glib) so you could write gnucash GUI in python (Ive actually re-written the gnome solitaire games program from guile into python as a learning exercise) as you say guile is a pain so there are few experts in it - and I have tried it (I made a multi-stock price scatter plot base on the single stock price scatter) - but Im using python in so many more cases trying to have 2 languages doesnt make sense 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. I agree - I looked into how to write gnucash in python (the gtk functions are the same so can eg directly read the existing ui xml files) but found that scheme/guile is not only used to write reports but also plays an intermediary role in some of the GUI elements so what should I do with the updates I was proposing to ask you about eg. no functionality to access budgets in current bindings - I have updates for these - one issue is that there is no C function to look up budgets by name - I hacked together a junk python ctypes glib accessor (ctypes is a python module which allows loading an existing shared library and calling the functions it defines) to access the list of budget guids that are maintained and then can use the existing budget list of guids function and write a python function to scan through those looking for a name David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Monday 13 January 2014 08:16:17 David Osguthorpe wrote: I am using the python bindings - in fact was just going to see about getting some patches to update the bindings. Just updated to 2.6.0 - looks as though some functions that used to exist no longer exist in the Account class so need to be removed from gnucash_business.py Ive noticed that the python bindings are not very pythonic - I have some updates which improve this eg account lookup used to require testing that the swig instance was None - this got updated somewhere between 2.4 and 2.6 so now the python class returns None - the pythonic way seems to me is to raise exception - which is what one of my updates does So I was going to email this list to see what is going on with the bindings and how such improvements could be added. Such updates will fail existing python code - such as the examples - although Ive found other cases where existing changes means some of the example python code no longer works David There is no formal python-bindings maintainer but I do welcome and apply submitted improvements. So if you have fixes please do file an enhancement request in bugzilla [1] and attach your patches to it. John's reply does raise a valid issue with the python bindings: they are not easily portable to OS X and Windows and currently disabled on these platforms. That's why gnucash is not implementing any core functionality directly in python and patches in that direction will most likely be refused. Having said I do consider the python bindings a useful and powerful feature that can help integrate gnucash in other workflows, automate repetitive tasks, simplify complex steps and so on. In short: gnucash should not depend on python due to porting difficulties, but I support the idea of well developed python bindings as a tool for personal customisation (albeit exclusively on a limited set of platforms). Specifically to your suggestions: regarding returning None vs raising an exception, I have no opinion. I don't use python enough myself to know what would be the most typical python way of doing things. Ideally if you implement changes that break the examples, please include code that fixes the examples as well. They're about the only documentation that exists for the python bindings and it would be very confusing if they stopped working. I'm looking forward to your patches. Geert [1] http://wiki.gnucash.org/wiki/Bugzilla ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
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
Re: Python bindings: patch, documentation, examples
On Jan 13, 2014, at 8:39 AM, David Osguthorpe david.osgutho...@gmail.com wrote: On Sun, Jan 12, 2014 at 08:14:11PM -0800, John Ralls wrote: * Who is maintaining the Python bindings and is there any roadmap to improve them? They're maintained enough to keep them compiling by the core team. They're not really part of our development plan, they're mostly just there. This is not good news to me - Ive been playing with these for my personal accounting eg updating stock prices, currencies - to take into account the vagaries of finance-quote failing in various ways - and unable to do currency histories - so can do a bulk update of prices every so often Sorry. We've consistently said that on this list. 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++. I dont understand why you would say this - Im using a lot of code with python (and Im on a Mac mainly also Linux - use gnucash via macports) in a lot of very different code systems eg pymol, ffmpeg) I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) - was trying to look at ways to write reports in python pygtk gives access to gtk functions (and glib) so you could write gnucash GUI in python (Ive actually re-written the gnome solitaire games program from guile into python as a learning exercise) as you say guile is a pain so there are few experts in it - and I have tried it (I made a multi-stock price scatter plot base on the single stock price scatter) - but Im using python in so many more cases trying to have 2 languages doesnt make sense You misunderstand me: Python on its own is a fine language, and I contribute regularly to another project (Gramps) which is a pure-python application. But Python does not excel for extending a program written in another language. It works well to use C and C++ libraries as the basis for a Python program, but Python wants to be in charge. GnuCash is built with Guile in charge, which rather rules out Python taking that role. Guile, for all of its faults, integrates much better with C than does Python and offers a much smaller footprint. This is because Guile was written expressly to be an embedded scripting language and Python was designed to be a general-purpose programming language with scripting bolted on as an afterthought. The problem with Python on the Mac is that we're supporting 5 versions of OS X, each of which has a different version of libpython.dylib. As I'm sure you know, the python wrappers need to link against that libpython.dylib and be able to dlopen the binary modules that accompany it. That's not a problem for the few folks who build GnuCash themselves, but it's not practical for general distribution. The solution I use for Gramps is to include Python in the app bundle, but that would require that anyone writing GnuCash extensions invoke that python instead of the one in /usr/bin. It's even worse on Windows, because we use MinGW, so we'd be linking against the MinGW libpython.dll. Anyone wanting to write Python extensions would have to install the ancient MinGW we use (v11) and run that Python. 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. I agree - I looked into how to write gnucash in python (the gtk functions are the same so can eg directly read the existing ui xml files) but found that scheme/guile is not only used to write reports but also plays an intermediary role in some of the GUI elements so what should I do with the updates I was proposing to ask you about eg. no functionality to access budgets in current bindings - I have updates for these - one issue is that there is no C function to look up budgets by name - I hacked together a junk python ctypes glib accessor (ctypes is a python module which allows loading an existing
Re: Python bindings: patch, documentation, examples
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
Re: Python bindings: patch, documentation, examples
On Monday 13 January 2014 08:39:36 David Osguthorpe wrote: On Sun, Jan 12, 2014 at 08:14:11PM -0800, John Ralls wrote: * Who is maintaining the Python bindings and is there any roadmap to improve them? They're maintained enough to keep them compiling by the core team. They're not really part of our development plan, they're mostly just there. This is not good news to me - Ive been playing with these for my personal accounting eg updating stock prices, currencies - to take into account the vagaries of finance-quote failing in various ways - and unable to do currency histories - so can do a bulk update of prices every so often You could volunteer to maintain/improve the bindings (no long-term commitment required) :) Seriously, GnuCash is a volunteer effort and none of the current developers is using the python- bindings much. Which results in the state John mentions. That's not to say they aren't nice to have. But it would help if someone was willing to spend some effort on it. 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++. I dont understand why you would say this - Im using a lot of code with python (and Im on a Mac mainly also Linux - use gnucash via macports) in a lot of very different code systems eg pymol, ffmpeg) IIRC OS X ships its own versions of python and each OS X release ships a different version. But the python bindings have to be compiled against the version that it will be used with. For Macports that's probably not an issue. It is for the OS X/Quarz version of GnuCash, which is available for download on the GnuCash website. That version can only support one version of python, and hence will only work on one OS X release. For Windows, python isn't even officially available. We'd have to resort to an installer available somewhere on the web. The official python on Windows is not compatible with Mingw, which we have based or Windows build on. Additionally if we start depending on python for GnuCash that would mean we'd have to add python to the windows installer, which would make it a *lot* bigger. It's already a large download as it is currently. I have a very hacky implementation in gnucash to call python from guile and return results to guile - I found existing libraries to do both (no updates to gnucash required - just a user prototype.scm file) - was trying to look at ways to write reports in python Impressive ! pygtk gives access to gtk functions (and glib) so you could write gnucash GUI in python (Ive actually re-written the gnome solitaire games program from guile into python as a learning exercise) For your personal use I'd say great! For the core of gnucash however it's currently not even clear if gtk will remain on our long-term roadmap. It's based on gobject which originally seemed like a good plan for portability. But developments in the last few years have been working against it. For example it has long not been possible to easily build gtk3 on Windows. Trying to port it to more extremely different platforms such as IOS or Android is near impossible (for completeness: support for those platforms are *not* on the roadmap, but I prefer to keep future options as open as possible). There have been several discussions in the (recent) past about the cost/benefit of switching to another gui framework (both Qt and WxWidgets are good potential candidates). Again this is a long-term goal at best. The first priority is to clean up the core api and rewrite it to C++. as you say guile is a pain so there are few experts in it - and I have tried it (I made a multi-stock price scatter plot base on the single stock price scatter) - but Im using python in so many more cases trying to have 2 languages doesnt make sense Agreed. Guile is more prominently present currently because gnucash once started off as a guile application. C has been added later and has gradually been replacing parts of guile. Python came much later still, but was never part of the core. 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
Re: Python bindings: patch, documentation, examples
David Osguthorpe david.osgutho...@gmail.com writes: 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++. I dont understand why you would say this - Im using a lot of code with python (and Im on a Mac mainly also Linux - use gnucash via macports) in a lot of very different code systems eg pymol, ffmpeg) We say this because there is no standard Python install on Mac or Windows, so when we build the GnuCash binary and ship an exe or dmg, we cannot know what version of Python the user might have. And if we choose wrong, it just wont work right. Our only option (AFAIK) would be to ship our own version of Python, but frankly that would increase the app size significantly for very little gain to the vast majority of users. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
Hi Henning, * Are there any other known/major users of the Python bindings? * Who is maintaining the Python bindings and is there any roadmap to improve them? While not a major user of the Python bindings I've contributed a few minor fixes and enhancements so far which are visiable in recent commits at https://github.com/Gnucash/gnucash/tree/trunk/src/optional/python-bindings Primarily, I've been looking to create a REST API for Gnucash using the Python bindings in order to provide a standard way of interfacing with Gnucash across various languages. My initial development is at https://github.com/Gnucash/gnucash/tree/trunk/src/optional/python-bindings/example_scripts/rest-api and I have some additional improvements I'm working on at the moment which isn't ready for public release, but I'd be happy to share with you if you wish. I'm focusing primarily on providing access to the business functions (creating and editing customers and, creating, editing, posting and paying invoices) as these are the areas I use most but this should also cover working with transactions and splits. If you have any queries about my development please let me know or feel free to email me directly if you don't think it would benefit including the list. Kind regards, Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings: patch, documentation, examples
On Jan 12, 2014, at 11:22 AM, Henning Jacobs henn...@jacobs1.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I recently discovered the great Python bindings and just updated http://wiki.gnucash.org/wiki/Python_Bindings to contain pointers to my scripts. Now my questions: * GncPrice does not contain a proper __init__, therefore I monkey patched it: https://github.com/hjacobs/gnucash-stock-portfolio/blob/master/gnucash_patch.py --- What's the best way to make a patch request for the original GnuCash Python bindings? File a bug with the patch attached: http://wiki.gnucash.org/wiki/Git#Patches * Are there any other known/major users of the Python bindings? Not as far as I know * Who is maintaining the Python bindings and is there any roadmap to improve them? They're maintained enough to keep them compiling by the core team. They're not really part of our development plan, they're mostly just there. 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++. 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. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
