Hi, after reading the mails of this thread, I would recommend one of the following ways:
1. Use a computer-readable format and some small editor for humans. The file-format could then be very simple -- I would recommend JSON. Or some kind of database (e.g. SQLite). For humans, you would have to write a (small/nice) graphical editor, where they can build the logic e.g. by clicking on buttons. This can also work for non-programmers, since the graphical editor can be adapted to the indended users, give help, run wizards etc. or: 2. Use a human-readable format and a parser for the computer. Then, the fileformat should be optimized for human readability. I would recommend a restricted subset of Python. This is much more readable/writeable for humans than any XML/JSON/YAML. And you could even add a graphical editor to further support non-programming-users. The computer would then need a special parser. But by using Python-expressions (only eval, no exec) and a parser for flow control (if/else/for/...) and assignments, this is not too much work and is good for many applications. I've written such a parser incl. some kind of (pseudo-)sandbox [2] for my template-engine "pyratemp" [1], and I've also used it for small user-created-procedures. [1] http://www.simple-is-better.org/template/pyratemp.html [2] It's not a real sandbox -- it's secured only by restricting the available commands. If you add unsafe commands to the pseudo-sandbox (e.g. Pythons "open"), the user can do bad things. But without manually adding unsafe commands, I don't know any way to get out of this pseudo-sandbox. And if you really need a sandbox which is more powerful than my pseudo-sandbox, you may want to have a look at the sandbox of PyPy. Trying to use a format which is both directly computer-readable (without a special parser) and well human readable never really works well in my experience. Then, you usually have to manually read/write/edit some kind of parse-tree, which is usually much harder to read/write than code. But if you want to do this, I recommend LISP ;). (By the way: If I did understand your mails correctly, your program would probably break if someone edits the XML-files manually, since you're using some kind of XML-like-fileformat with many non-intuitive assumptions.) Roland PS: On Wed, Aug 24, 2016 at 04:58:54PM +0200, Frank Millman wrote: > Here is a JSON version - > > { > "case": { > "compare": { > "-src": "_param.auto_party_id", > "-op": "is_not", > "-tgt": "$None", > "case": { > "on_insert": { > "auto_gen": { "-args": "_param.auto_party_id" } > }, > "not_exists": { > "literal": { "-value": "<new>" } > } > } > } > } > } I think this is not really good. In JSON, you also have lists, and in this case, it would probably be better to use some lists instead of dicts, e.g.: [ ["if", ["_param.auto_party_id", "is not", "None"], ["if", ["on_insert"], ["set", "value", ["call", "auto_gen", "_param.auto_party_id"]]], ["elif", ["not_exists"], ["set", "value", "'<new>'"]] ] ] I think this is much more readable than your XML-code and the auto-converted JSON. And it's even less ambigious. (How do you distinguish between the variable _param.auto_party_id and the string "_param.auto_party_id" in your XML-example?) -- https://mail.python.org/mailman/listinfo/python-list
