Paolo Bonzini <pbonz...@redhat.com> writes:
> On 03/08/20 13:28, Markus Armbruster wrote:
>>>> We could remove them from the QAPI schema language. Flag day, and
>>>> git-blame becomes pretty much useless for a couple of years.
>>> Is that a nack or a "whatever"?
>> It's "is this really worth the trouble?" I guess that's halfway between
>> NAK and whatever, ready to be moved in either direction by arguments :)
>
> In general it seems like a good idea to use a standard file format and
> not "a standard file format except for two characters". :) We also
> wouldn't be having discussions on editors.
No argument. But towards which standard file format should the schema
evolve?
* Standard JSON: no comments, no go
* JSON with # comments: need to change strings from ' to "
* JavaScript: need to change comments from # to //
* Python: may want to switch bool literals from true, false to True,
False
> That said, after a bit more research I'm skeptical about the possibility
> of using an off-the-shelf parser because most of them either don't
> support comments, or are based on YAJL which simply discards comments.
>
> Since '//' comments are harder to parse than "#" comments, this would
> actually _add_ code instead of removing it. Also since our doc comment
> syntax uses "##" as a delimiter, we'd have to bikeshed what the doc
> comments would look like ("//!", "///", etc.).
Doc comments don't have to be comments in the schema language. They
could be doc strings. Requires decent support for long strings, which
JSON does not provide.
> This means the two parts might be considered separately:
>
> - replacing single-quote with double-quote strings
>
> - replacing # comments with //
If all we want is decent editor support out of the box, then rename to
.py, and drop the modelines. No merge conflicts, no git-blame
pollution.
To make the .py files actual Python, additionally rename the bool
literals. Much, much less churn than massaging all strings or all
comments.
