On 12/10/2009 06:03 PM, Anthony Liguori wrote:
Avi Kivity wrote:
On 12/10/2009 02:56 PM, Anthony Liguori wrote:
I'd prefer an empty dict. I actually prefer that over null.
Depends. Key not present suggests the feature is not implemented.
Value is null suggests the feature is not used. Both key and value
present suggest the feature is in implemented and active.
What I suggested to Luiz was that all info commands return a
dictionary. The main reason was that for most commands, we can extend
the commands in a compatible way by adding new fields to the dictionary.
Oh yes.
My expectation is that there will be a lot of client code that does:
hpet_info = qmp.info_hpet()
if hpet_info.has_key('period'):
period = hpet_info['period']
else:
period = 100 # old qemu's has a fixed period of 100ns
So in keeping with this idiom, I think that checking
name_info.has_key('name') is a more meaningful way to determine
whether the virtual machine has been given a name vs comparing
name_info['name'] == None.
But we have two null conditions to check for, in an extendible dictionary:
1. The feature is unknown to qemu
2. The feature is known to qemu, but disabled
So, "if 'field' in result:" tests the former, and "if result['field']:"
tests the latter.
In your example, a period of None makes no sense, so it would be
sufficient to
period = hpet_info.get('period', 0.100)
--
error compiling committee.c: too many arguments to function
