Most Pythonic way to store (small) configuration

[Chris Angelico]

On Thu, Aug 6, 2015 at 5:33 PM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> On Thursday 06 August 2015 10:07, Chris Angelico wrote:
>
>> On Thu, Aug 6, 2015 at 9:43 AM, Tim Chase <python.list at tim.thechases.com>
>> wrote:
>>> Significant whitespace?  Not usually simple (just stuck touching a
>>> project where someone committed with tons of trailing whitespaces.
>>> grumble), so strip 'em off as if they're an error condition.  I've
>>> never had a config-file where I wanted leading/trailing whitespace as
>>> significant.
>>
>> If you're configuring a prompt, sometimes you need to be able to
>> include a space at the end of it.
>
> "Sometimes"? What sort of filthy perv doesn't separate their prompts from
> the user input with at least one space? Disgusting, I call it.
>
>     this is a prompt and this isn't
>
> versus
>
>     this is a promptand this isn't
>
> Come the revolution, anyone who writes the second will be taken out and
> shot.

Oh, well, there are these people in backwards nations that still have
prompts that look like this:

C:\>

and have no space after them. I *was* trying to be courteous, but
maybe courtesy is wasted on those who'll be shot come the revolution
anyway.

> The right solution to that is to have the display function add a space to
> the end of the prompt if there isn't already one, that way you don't need to
> care about putting a space at the end of the prompt yourself.

That's an option that solves one specific instance of the problem, but
I'm sure there are other places where you may or may not want a
trailing space, so it needs a marker.

>> Since trailing whitespace on a line
>> in the file itself is a bad idea, you need some way of marking it.
>
> I'm partial to one of two schemes:
>
> - strings need to be quoted, so leading and trailing spaces are easy:
>
>   key = " this has both leading and trailing spaces "

Yeah, this is fine for a lot of cases. It does add small complexity,
though, to the simple case where you're setting simple tokens as
values.

> - strings don't need to be quoted, and spaces are significant *except*
>   at  the ends of the string:
>
>   key = this has no leading or trailing spaces
>
>   If you need spaces at the end, use an escape sequence:
>
>   key = \sthis has both leading and trailing spaces\s
>
> say, or ^SP or \N{SPACE} or whatever floats your boat. Unless your
> requirements are limited to only printable ASCII strings, you're going to
> need to provide some sort of escape sequence anyway, to allow (say)
> newlines.

This is starting to get toward a full-blown DSL, which is costly. At
this point, you may as well go for something well-known, which is what
this thread's all about.

A compromise might be: Unquoted strings get trimmed and are restricted
to one line, but if you want leading/trailing spaces, or
leading/trailing quote characters, or embedded newlines, or Unicode
escapes, you must first put quotes around the string.

server = 127.0.0.1
message = "Hi there!\nTwo line message being delivered."
windows_path = c:\users\adam

That way, you pay the complexity cost of full string parsing only if
you actually need it.

ChrisA