From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFQ5-0001qo-GJ for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:58:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdFQ2-0006lE-Q6 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:58:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdFQ2-0006kq-J3 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 05:58:42 -0400 Date: Wed, 1 Apr 2015 11:58:38 +0200 From: Kevin Wolf Message-ID: <20150401095838.GD3593@noname.str.redhat.com> References: <1427227433-5030-1-git-send-email-eblake@redhat.com> <1427227433-5030-18-git-send-email-eblake@redhat.com> <20150331152359.GC4748@noname.redhat.com> <87sicl2akl.fsf@blackfin.pond.sub.org> <20150401083150.GB3593@noname.str.redhat.com> <87vbhgur9x.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87vbhgur9x.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v5 17/28] qapi: Allow true, false and null in schema json List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: famz@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com, lcapitulino@redhat.com Am 01.04.2015 um 11:33 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > Am 31.03.2015 um 22:09 hat Markus Armbruster geschrieben: > >> Kevin Wolf writes: > >> > >> > Am 24.03.2015 um 21:03 hat Eric Blake geschrieben: > >> >> From: Fam Zheng > >> >> > >> >> In the near term, we will use it for a sensible-looking > >> >> 'gen':false inside command declarations, instead of the > >> >> current ugly 'gen':'no'. > >> >> > >> >> In the long term, it will allow conversion from shorthand > >> >> with defaults mentioned only in side-band documentation: > >> >> 'data':{'*flag':'bool', '*string':'str'} > >> >> into an explicit default value documentation, as in: > >> >> 'data':{'flag':{'type':'bool', 'optional':true, 'default':true}, > >> >> 'string':{'type':'str', 'optional':true, 'default':null}} > >> > > >> > FWIW, I don't think that's a very friendly syntax for humans, it's a bit > >> > verbose. But that's no reason not to allow true/false/null, of course. > >> > >> Here's my current thinking. > >> > >> Longhand: > >> > >> # mandatory > >> 'name': { 'type': 'str' } > >> # optional, with a default > >> 'flag': { 'type': 'bool', 'default': true } > >> # optional, no default > >> 'string': { 'type': 'str', 'default': null } > >> > >> Presence of 'default' implies optional. > >> > >> Equivalent shorthand, if any: > >> > >> 'name': 'str' > >> '*string': 'str' > > > > A nice shorthand for defaults would be: > > > > '*name': 'str' = 'default' > > > > Though that would be neither valid JSON nor Python any more. Do we > > actually rely on this property anywhere or is it only parsed by the QAPI > > generator anyway and we can extend the language in such ways? > > I guess JSON / Python was chosen as QAPI schema language to save us the > bother of defining a syntax and building the tools to work with it, like > an Emacs mode. JSON's not exactly my favourite choice, but at least > it's not XML. > > What we have now isn't JSON, but it's still a subset of Python, and the > Python tools work. If we go beyond Python, they'll break. > > If we decide to sacrifice these tools for readability, then we can just > as well replace the syntax entirely. Preferably by something where I > don't have to put every identifier in quotes. > > In short, you're welcome to hack up qapi.py some more for schema > readability, but either keep Emacs Python mode working, or provide a > replacement :) What features does this Python mode provide that you use? For the JSON schema, the only thing I really use from the editor is syntax highlighting, and that shouldn't be bothered by an addition like this (in vim it doesn't hurt anyway). I also don't use any other Python tools, though I'm not sure that none exist that would make sense with the schema. So if there are practically relevant advantages in being real Python code, then we need to consider that, of course. That's why I was asking. But if there aren't, it's just an arbitrary restriction that could be removed. Kevin