> great that you don't need quotes for keys, but why do you need quotes for values ...
Quotes for string values are very important because they avoid ambiguity [1][2] and the type of quotes (single or double) tells the deserializer how to treat the string: as an ordinary string (which may have escape sequences) or a raw string.
> ... is there no way to simplify data types a bit to be able to get rid of those?
String values already benefit from a simplification: quotes can be placed inside a string (ordinary or raw) without a backslash to escape them. This is not the case in TOML: "Since there is no escaping, there is no way to write a single quote inside a literal string enclosed by single quotes. Luckily, TOML supports a multi-line version of literal strings that solves this problem." (https://toml.io/en/v1.0.0#string)
> for configs it's surprisingly poor with only a-z_ keys
Config dictionary keys follow the identifier naming rules in C to enable mapping between config keys and variables. Therefore, one could (at least in Python) pass a config dict as arguments to functions like this:
from paradict import ConfigFile
def my_func(arg1=42, arg2=True, **kwargs):
pass
# load user_config from the 'config.dict' file
path = "/path/to/config.dict"
confile = ConfigFile(path)
user_config = confile.get("user")
# pass user_config to my_func
my_func(**user_config)
Re raw string - so let only it be quoted (or maybe better yet - vice versa, no quotes, no expansion), that's a valid mechanism to signal type. Just like you'd need a quote if you wanted to add whitespace are the beginning of a regular string (unless you make it only 1 space after = a valid separator)
I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match, so how does allowing Unicode make it different?
> I don't get the a-z benefit in the argument case - the user must type "arg1" precisely for the argument names to match...
Absolutely ! The user must type "arg1" precisely because this is part of the implicit agreement between the user and the system. If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user.
I plan to build two flagship projects to leverage Paradict binary and textual formats: a lightweight database and an automation tool. The automation tool will consume a configuration file a bit like another project of mine does (https://github.com/pyrustic/backstage).
And this is where I join you. I think we'll both agree that since a shell command is already likely to have quotes around some of its arguments, it's very annoying to have to put extra quotes around it. So I'm thinking of introducing a Command data type:
# entering 'start' in the command line will run the
# unquoted string at the right side of the backtick (`)
start = `program -f --flag "hello world"
[1] https://linuxopsys.com/topics/bash-backticks-vs-dollar-paren...
> If the user forgets to type "arg1", the default value will be taken into account. If the user adds an unexpected key (a typo for example), it will be stored in "kwargs" and then ignored or used to warn the user.
But this is no different with nonASCII, so it's not an argument for it.
[user]
name = 'John Doe'
'région': 'Himalaya'
Characters like œ [1] or ï [2] are common in my everyday vocabulary, but I've always stuck to ASCII and underscore in my code sources for reasons like keyboard layout availability, portability, IT legacy, etc.
> Also it's strange that your view of the config users is so limited as to only include programmers
The Paradict texual format has two modes (data and config) for this very reason: we need a relaxed version of the data mode.
I will continue to weigh the cons and pros for the characters allowed in the config keys. At the moment, some of the pros are:
- Developer experience: the 'dictionary unpacking' [3][4][5] capability in programming languages is really cool.
- Target population: I assume that the majority of configfile users are programmers and those who are not are used to following more complicated rules (e.g. formulas in spreadsheets).
- Least astonishment principle: people already know by heart the rules for naming identifiers in C (which inspired many other languages).
- The "key = value" syntax is the same as the variable assignment syntax.
- With rendering ASCII as a monospaced font, we won't complain about a character being visually similar to a space or the equal sign (=).
[1] https://en.wikipedia.org/wiki/%C5%92
[2] https://en.wikipedia.org/wiki/%C3%8F
[3] https://reference.codeproject.com/python3/dictionaries/pytho...
[4] https://discuss.python.org/t/syntax-for-dictionnary-unpackin...
[5] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...