[libvirt] [PATCH v2] python: add virDomainGetCPUStats python binding API

[Eric Blake]

On 03/21/2012 07:47 AM, Guannan Ren wrote:
>      I get your points,  sorry I don't express my idea clearly.
>      According to my experience, for PyObject_IsTrue, all of non-null
> objects
>      belongs to True,  null objects like {}, ""(str) ,None, False
>      counts as False,

Correct.

>  it's good way to work with Pybool_check to ensure
>      the type of value given by upper python code is right type.  The
> wrapper
>      should do the job.

Only if we want to be sticklers.  For reference, in C,

void foo(bool x);

can be called with a bool (foo(true) or foo(false)), an int (foo(1) or
foo(0)), a pointer (foo("") or foo(NULL)).  That is, C gives you
automatic conversion.

In Java, you _have_ to pass a boolean, where

void foo(boolean x) {}

must be called as foo(true), foo(i != 0), foo(str != null), and so
forth, which puts more burden on the caller to do the type conversion up
front.

Which style describes python code?  Is python type-strict, where you
have to manually convert to bool in contexts that demand a PyBool, or do
you get automatic conversion where the empty string, None, integer 0,
and other python objects can be implicitly used in place of the actual
False object?  Depending on that answer determines whether you should be
using PyBool_Check and rejecting invalid types, or whether you allow all
python objects with their normal conversion to boolean.  And my limited
understanding (given that I have not done much python coding) is that
python is relaxed like C, not strict like Java.  In other words, I think
we should allow users to call dom.getCPUStats(0, 0) rather than forcing
them to call dom.getCPUStats(False, 0), if that is the convention
allowed elsewhere in native python code.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120321/414ee35f/attachment-0001.sig>