Also have a look at group Python_bindings.
They can be found in src/optional/python-bindings.
To enable them in the compilation process you have to add --enable-python-bindings to the call of ./configure.
As a starting point have a look at the example-scripts.
The python bindings supply the ability to access a wide range of the core functions of GnuCash. You can read and write Transactions, Commodities, Lots, access the business stuff... You gain the ability to manipulate your financial data with a flexible scripting language.
Not everything GnuCash can is possible to access though. The bindings focus on basic accounting functions. Have a look at the examples to get an impression.
The python-bindings are generated using SWIG from parts of the source-files of GnuCash.
SWIG extracts informations from the c-sources and provides access to the structures to python. It's work is controlled by interface files :
If you have generated your own local doxygen documentation (by "make doc") after having compiled the python-bindings, doxygen will include SWIGs output-files. It's actually quite interesting to have a look at them through doxygen, because they contain all that you can access from python.
This c-style-api is the bottom layer. It is a quite raw extract and close to the original source. Some more details are described further down.
For some parts there is a second layer of a nice pythonic interface. It is declared in
>> import gnucash
You can access the structures of the high level api. For Example you get a Session object by
Here you will find easy to use things. But sometimes - and at the current level rather sooner than later - you may be forced to search for solutions at the :
>> import gnucash
The c-style-api can be accessed via gnucash.gnucash_core_c. You can have a look at all the possibilities at gnucash_core_c.py.
You will find a lot of pointers here which you can just ignore if input and output of the function have the same type.
For example you could start a session by gnucash.gnucash_core_c.qof_session_begin(). But if you just try
you will get an error message and realize the lack of convenience for you have to add the correct function parameters.
Not all of the available structures will work. SWIG just takes everything from the sources that it is fed with and translates it. Not everything is a working translation, because not everything has been worked through. At this point you are getting closer to the developers who you can contact at the mailing-list firstname.lastname@example.org. There may be a workaround. Maybe the problem can only be fixed by changing SWIGs input files to correctly translate the c-source. Feel free to post a question at the developers list. It may awaken the interest of someone who creates some more beautiful python-interfaces.
The start would surely be the high-level api for you can be quite sure to have something working and you will maybe find explanations in the example-scripts. If you search for something that is not yet implemented in that way you will have to take your way to the c-style-api.