John Snow <js...@redhat.com> writes: > On 7/30/20 9:24 AM, Daniel P. Berrangé wrote: >> On Thu, Jul 30, 2020 at 01:51:10PM +0200, Markus Armbruster wrote: >>> Daniel P. Berrangé <berra...@redhat.com> writes: >>> >>>> modify them so that we can load the >>>> files straight into the python intepretor as code, and not parse >>>> them as data. I feel unhappy about treating data as code though. >>> >>> Stress on *can* load. Doesn't mean we should. >>> >>> Ancient prior art: Lisp programs routinely use s-expressions as >>> configuration file syntax. They don't load them as code, they read them >>> as data. >>> >>> With Python, it's ast.parse(), I think. >> >> Yes, that could work >> > > I use a similar trick for parsing "Fuzzy JSON" inside of qmp-shell. > > It's cute, and I'm not really proud of it. > >> >>>> struct: ImageInfoSpecificQCow2 >>>> data: >>>> compat: str >>>> "*data-file": str >>>> "*data-file-raw": bool >>>> "*lazy-refcounts": bool >>>> "*corrupt": bool >>>> refcount-bits: int >>>> "*encrypt": ImageInfoSpecificQCow2Encryption >>>> "*bitmaps": >>>> - Qcow2BitmapInfo >>>> compression-type: Qcow2CompressionType >>>> >>>> >>>> Then we could use a regular off the shelf YAML parser in python. >>>> > > I have a prototype where I started this, but I use "---" as a document > separator to allow us multiple definitions per file so that the > nesting remains pleasant. > > (YAML does not allow you to duplicate field names.) > >>>> The uglyiness with quotes is due to the use of "*". Slightly less ugly >>>> if we simply declare that quotes are always used, even where they're >>>> not strictly required. >>> >>> StrictYAML insists on quotes. >> >> I wouldn't suggest StrictYAML, just normal YAML is what pretty much >> everyone uses. >> > If we came up with a different way to mark a field as optional >> instead of using the magic "*" then we wouldn't need to quote >> anything >> > > I have a YAML prototype branch where I use `?field` to indicate > optional syntax. It works just fine, at the expense of being slightly > new to people. > > I tested with normal YAML, but I was thinking about adopting strict > YAML because Markus wanted some assurance we wouldn't get lost in the > weeds using complex feature of YAML. > > (Or, shoot ourselves entirely by accident.) > > My prototype doesn't use anything that Strict YAML prohibits, so I > thought it was a good idea. > > IF -- IF IF IF IF IF we decide that actually we need the crazy > horsepower of standard YAML, or that strict YAML is too buggy -- we > could always just replace it. No real big deal. > >>> I hate having to quote identifiers. There's a reason we don't write >>> >>> 'int' >>> 'main'('int', 'argc', 'char' *'argv'[]) >>> { >>> 'printf'("hello world\n"); >>> return 0; >>> } >>> > > Fair enough ... but there's no special meaning to quoting or not > quoting the RHS in YAML, so maybe it's best to avoid pretending like > there's a structural semantic between an identifier and a string > there. > > (Since they're both just strings, and the semantic difference is > picked up inside the QAPI generator post-parse.)
You wish... An unquoted right hand side is a string, unless it can be interpreted as something else. For instance, when something else is one of the eleven(?) ways to say false, you have a variation of YAML's Norway problem: https://hitchdev.com/strictyaml/why/implicit-typing-removed/ >>>> struct: ImageInfoSpecificQCow2 >>>> data: >>>> "compat": "str" >>>> "*data-file": "str" >>>> "*data-file-raw": "bool" >>>> "*lazy-refcounts": "bool" >>>> "*corrupt": "bool" >>>> "refcount-bits": "int" >>>> "*encrypt": "ImageInfoSpecificQCow2Encryption" >>>> "*bitmaps": >>>> - "Qcow2BitmapInfo" >>>> "compression-type": "Qcow2CompressionType" >>>> >>>> With the use of "---" to denote the start of document, we have no trouble >>>> parsing our files which would actually be a concatenation of multiple >>>> documents. The python YAML library provides the easy yaml.load_all() >>>> method. >>> > > Nevermind the earlier comment, then. > >>> Required reading on YAML: >>> https://www.arp242.net/yaml-config.html >> >> I don't think this is especially helpful to our evaluation. You can write >> such blog posts about pretty much any thing if you want to pick holes in a >> proposal. Certainly there's plenty of awful stuff you can write about >> JSON, and Python. >> >>> Some of the criticism there doesn't matter for our use case. >> >> Yeah, what matters is whether it can do the job we need in a way that is >> better than what we have today, and whether there are any further options >> to consider that might be viable alternatives. The sheer complexity of YAML puts me off. The spec exceeds 20k words. > I guess I'll dust off the work I have already to show the class. Prototype code should beat guesswork.