One way that I like to create templates for config files is to write the config
file in a way that can be used with `str.format` if I read in the entire config
file as a string before re-saving it or sending it somewhere.* The config file
contains a half dozen or dozen variables. Another several dozen variables are
pretty much permanent. This approach works for me in the sense that batch
submits over several combinations of variables is just a few lines of code, and
when I revisit a job after quite some time, the curly braces in the config file
template remind me what settings (might) require my attention. The problem lies
in what to do about defaults. Including a formatted variable in the template
file requires that the variable be included in my call to `format` otherwise
I'll get a `KeyError`. For my part, I can work around this by including a
companion '.py' file that includes a `dict` of default values. What I pine for
is the ability to discard this extra '.py' file, and its WYS
INWYG heresy by enabling a way to enable defaults in the processing of
formatted strings. One such way would be to modify the format string spec. I am
not sure how this might be done, so I cannot make a smart proposal on that one.
Another way, although it might not be the most popular, is to allow for inline
exception handling of the sort proposed in PEP 463.
To me, the following does not look so bad:
Config file:
```
...
BAUD: {baud except 9600}
...
```
Template updating code snippets:
```
with open('config.yaml', 'r') as f:
txt = f.read()
options = {'baud': 19200}
new_txt1 = txt.format(options) # BAUD: 19200 is now in new_txt1
options = {}
new_txt2 = txt.format(options) # BAUD: 9600 is now in new_txt2
```
Curious to know anyone's thoughts on the subject, particularly anyone else who
is in the habit of hastily writing config files. Apologies if bringing up a
rejected PEP on my first thread causes any irritation, but I swear I would not
have done it if string formatting weren't so useful. I thank you for my cookie
and now I would like some milk.
* - I'm aware that there can be security risks in this approach, but I am
working in a walled off system (not public) where it is unlikely that I or
anyone else can do much damage even if we wanted to.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/L2VQKTKZDJ3YXIZNZE4SBS3JPT5L552A/
Code of Conduct: http://python.org/psf/codeofconduct/
