X-Received: by 10.13.230.130 with SMTP id p124mr10841172ywe.24.1438822895887; Wed, 05 Aug 2015 18:01:35 -0700 (PDT)
X-Received: by 10.50.253.5 with SMTP id zw5mr5825igc.9.1438822895854; Wed, 05 Aug 2015 18:01:35 -0700 (PDT)
Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!69no4135397qgl.1!news-out.google.com!o13ni7202igw.0!nntp.google.com!f3no8136846igg.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.python
Date: Wed, 5 Aug 2015 18:01:35 -0700 (PDT)
In-Reply-To: <mailman.1247.1438808479.3674.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=117.195.51.203; posting-account=mBpa7woAAAAGLEWUUKpmbxm-Quu5D8ui
NNTP-Posting-Host: 117.195.51.203
References: <87k2teq9tb.fsf@Equus.decebal.nl> <mailman.1240.1438781266.3674.python-list@python.org> <36333f24-3bda-4534-b22f-20c99e8d791c@googlegroups.com> <mailman.1247.1438808479.3674.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <55e15744-67f3-4055-9948-ec7bfaafdd58@googlegroups.com>
Subject: Re: Most Pythonic way to store (small) configuration
From: Rustom Mody <rustompmody@gmail.com>
Injection-Date: Thu, 06 Aug 2015 01:01:35 +0000
Content-Type: text/plain; charset=ISO-8859-1
X-Received-Bytes: 3643
X-Received-Body-CRC: 1632426319
Xref: csiph.com comp.lang.python:95048

On Thursday, August 6, 2015 at 2:31:52 AM UTC+5:30, Tim Chase wrote:
> On 2015-08-05 06:37, Rustom Mody wrote:
> > >   config = {}
> > >   with open('config.ini') as f:
> > >     for row in f:
> > >       row = row.strip()
> > >       if not row or row.startswith(('#', ';')):
> > >         continue
> > >       k, _, v = row.partition('=')
> > >       config[k.strip().upper()] = v.lstrip()
> > > 
> > > which is pretty straight-forward and easy format to edit.
> > > 
> > > -tkc  
> > 
> > JSON handles basic types like this:
> > >>> from json import loads
> > >>> loads("""{"anInt":1, "aString":"2"}""")  
> > {'aString': '2', 'anInt': 1}
> 
> But requires the person hand-editing the file to make sure that
> opening braces close, that quoted text is properly opened/closed, has
> peculiarities regarding things following back-slashes, etc.
> 
> There's a certain simplicity to simply having key/value pairs
> separated by an "=" and then letting the application do whatever it
> needs/wants with those key/value strings.
> 
> -tkc

I just checked that literal_eval accepts comments.
So thats one plus for that.
However I must admit that in checking that out I was faced with more than
(I) expected unfriendly error messages like

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
    return _convert(node_or_string)
  File "/usr/lib/python3.4/ast.py", line 62, in _convert
    in zip(node.keys, node.values))
  File "/usr/lib/python3.4/ast.py", line 61, in <genexpr>
    return dict((_convert(k), _convert(v)) for k, v
  File "/usr/lib/python3.4/ast.py", line 83, in _convert
    raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Name object at 0x7fe1173ebac8>


By contrast here is a more friendly error message (had put a comma where a colon
required)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/ast.py", line 46, in literal_eval
    node_or_string = parse(node_or_string, mode='eval')
  File "/usr/lib/python3.4/ast.py", line 35, in parse
    return compile(source, filename, mode, PyCF_ONLY_AST)
  File "<unknown>", line 2
    "i", 1}

So overall whether ast.literal_eval is a good idea is not clear to me