diff options
author | Guannan Ren <gren@redhat.com> | 2013-03-21 11:24:49 +0800 |
---|---|---|
committer | Guannan Ren <gren@redhat.com> | 2013-03-21 11:24:49 +0800 |
commit | 48c23ca1f14b8cfe6ab52138f9ba5835198288be (patch) | |
tree | d960368f1c7b4f361d6a9ad861bbf4fbb06d7e8e /libvirt-override-virStoragePool.py | |
parent | 2ccc4d0f7ccb5e1d3f122816270bff50adce43c9 (diff) | |
download | libvirt-python-split-48c23ca1f14b8cfe6ab52138f9ba5835198288be.tar.gz libvirt-python-split-48c23ca1f14b8cfe6ab52138f9ba5835198288be.tar.xz libvirt-python-split-48c23ca1f14b8cfe6ab52138f9ba5835198288be.zip |
python: fix bindings that don't raise an exception
For example:
>>> dom.memoryStats()
libvir: QEMU Driver error : Requested operation is not valid:\
domain is not running
There are six such python API functions like so.
The root reason is that generator.py script checks the type of return
value of a python stub function defined in libvirt-api.xml or
libvirt-override-api.xml to see whether to add the raise clause or not
in python wrapper code in libvirt.py.
The type of return value is supposed to be C types.
For those stub functions which return python non-integer data type like
string, list, tuple, dictionary, the existing type in functions varies
from each other which leads problem like this.
Currently, in generator.py, it maintains a buggy whitelist for stub functions
returning a list type. I think it is easy to forget adding new function name
in the whitelist.
This patch makes the value of type consistent with C type "char *"
in libvirt-override-api.xml. For python, any of types could be printed
as string, so I choose "char *" in this case. And the comment in xml
could explain it when adding new function definition.
<function name='virNodeGetCPUStats' file='python'>
...
- <return type='virNodeCPUStats' info='...'/>
+ <return type='char *' info='...'/>
...
</function>
Diffstat (limited to 'libvirt-override-virStoragePool.py')
0 files changed, 0 insertions, 0 deletions