From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIlou-0002oA-9J for qemu-devel@nongnu.org; Thu, 10 Dec 2009 11:24:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIlop-0002ir-CE for qemu-devel@nongnu.org; Thu, 10 Dec 2009 11:24:47 -0500 Received: from [199.232.76.173] (port=41861 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIlop-0002id-8B for qemu-devel@nongnu.org; Thu, 10 Dec 2009 11:24:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32863) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIlop-0008KB-FP for qemu-devel@nongnu.org; Thu, 10 Dec 2009 11:24:43 -0500 Message-ID: <4B2120C6.1020004@redhat.com> Date: Thu, 10 Dec 2009 18:24:38 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObject References: <1260376078-8694-1-git-send-email-lcapitulino@redhat.com> <1260376078-8694-11-git-send-email-lcapitulino@redhat.com> <20091210095237.38cafe5c@doriath> <4B20F003.6070409@linux.vnet.ibm.com> <4B2119F9.6010003@redhat.com> <4B211BE2.60907@linux.vnet.ibm.com> <4B211D6F.7020906@redhat.com> <4B211FDF.4070509@linux.vnet.ibm.com> In-Reply-To: <4B211FDF.4070509@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 12/10/2009 06:20 PM, Anthony Liguori wrote: > > By the same token, wouldn't you probably do: > > name = hpet_info.get('name', None) > For name, yes. For an optional feature where you're interested in knowing both its existence and its value (if it exists), no. > Let me put it another way, I don't think adding null to the json > parser and incorporating it into this command is a good idea at this > stage in the release so if we want to do something like this, we need > to defer it to 0.13. > > I agree there are some instances where null could be useful. I think > we can get away without it here though. For 'name', definitely, since it's known to exist. It would be nice to have consistency in how features are presented, though. -- error compiling committee.c: too many arguments to function