From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdGeA-0001Ox-Ry for qemu-devel@nongnu.org; Wed, 01 Apr 2015 07:17:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YdGe3-0003Ky-R2 for qemu-devel@nongnu.org; Wed, 01 Apr 2015 07:17:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YdGe3-0003Ks-Jq for qemu-devel@nongnu.org; Wed, 01 Apr 2015 07:17:15 -0400 Date: Wed, 1 Apr 2015 13:17:11 +0200 From: Kevin Wolf Message-ID: <20150401111711.GE3593@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> <20150401095838.GD3593@noname.str.redhat.com> <87pp7ot8k7.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pp7ot8k7.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: lcapitulino@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, wenchaoqemu@gmail.com Am 01.04.2015 um 13:03 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > 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? > > Syntax highlighting, automatic indentation, possibly more I rely on > without noticing. My fingers know, but they don't talk. > > > 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. > > If we decide to revise the decision to borrow existing syntax and roll > our own instead, let's 'make' 'our' 'own' 'syntax' 'not' 'suck'. > > Anyway, we got bigger fish to fry right now. Okay, I got it. Asking me to create a completely new syntax and the generator for it is the longhand version for "no". Kevin