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 WYSINWYG 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.