Recommended "new" way for config files
Peter
There seems to be several strategies to enhance the old ini-style config
files with real python code, for example:
1) the documentation tool sphinx uses a python file conf.py that is
exefile(d) , but execfile is suppressed in Python 3
2) there is a module cfgparse on sourceforge that supports a hybrid style
3) modern tools like ipython seems to favor a new style based on python
code config files but also support a hybrid style mixing .ini files and
python code files.
4) I could use __import__ to import modules based on some command line
options
Is there a strategy that should be prefered for new projects ?
thanks
peter
Lie Ryan
> Is there a strategy that should be prefered for new projects ?
The answer is, it depends.
Jean-Michel Pichavant
> Hi
> There seems to be several strategies to enhance the old ini-style
> config files with real python code, for example:
>
> 1) the documentation tool sphinx uses a python file conf.py that is
> exefile(d) , but execfile is suppressed in Python 3
> 2) there is a module cfgparse on sourceforge that supports a hybrid style
> 3) modern tools like ipython seems to favor a new style based on
> python code config files but also support a hybrid style mixing .ini
> files and python code files.
> 4) I could use __import__ to import modules based on some command line
> options
>
>
>
> peter
I would add the standard module ConfigParser
http://docs.python.org/library/configparser.html to your list.
I don't know exactly what you intend to do with point 4/, but I would
exclude it if any other point may fit. Imports can become tricky when
used out of the common way. Anyway, hacking the import statement for
managing configuration files does not sound very appropriate.
The .ini file is the simpliest solution, at least from the user point of
view, no need to learn any python syntax.
However, speeking for myself, I am using python coded configuration
files, but: we all worship python in the team and thus are familiar with
it.
JM
Robert Kern
> Hi
> There seems to be several strategies to enhance the old ini-style config
> files with real python code, for example:
>
> 1) the documentation tool sphinx uses a python file conf.py that is
> exefile(d) , but execfile is suppressed in Python 3
Only because it is redundant, not because it is a discouraged approach. You can
still read the file and exec() the resulting string.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
Peter
> I would add the standard module ConfigParser
> http://docs.python.org/library/configparser.html to your list.
of course, that was the implicit starting point of my request, when
talking about .ini files.
> I don't know exactly what you intend to do with point 4/,
It would allow me to select different conf.py files with command line
switches, like for example a -c <alternative conf file> option.
> but I would exclude it if any other point may fit. Imports can become
> tricky when used out of the common way. Anyway, hacking the import
> statement for managing configuration files does not sound very
> appropriate.
>
Would this be considered a hack ?
#!/usr/bin/env python
import sys
# parse command line options here
if option='standard':
const = __import__('consts')
else:
const = __import__('alternative_consts')
> The .ini file is the simpliest solution, at least from the user point
> of view, no need to learn any python syntax.
I am speaking from the point of view of a python programmer, and I find
the .ini restrictions not necessarily simple, for example when dealing
with structured data (I suppose it is trivial to specify a dictionnary
or a list for the purpose of my request) For example, configuration
files for the logging module get unwieldy when you specify several
loggers , handlers, formatters etc, because you have to break down
structured data ( objects ) to name,value pairs.
> However, speeking for myself, I am using python coded configuration
> files, but: we all worship python in the team and thus are familiar
> with it.
>
so do I.
> JM
>
>
So what is the "worshipped" approach, when you need more than name=value
pairs ?
Peter
Chris Rebert
<snip>
>> The .ini file is the simpliest solution, at least from the user point of
>> view, no need to learn any python syntax.
>
> I am speaking from the point of view of a python programmer, and I find the
> .ini restrictions not necessarily simple, for example when dealing with
> structured data (I suppose it is trivial to specify a dictionnary or a list
> for the purpose of my request) For example, configuration files for the
> logging module get unwieldy when you specify several loggers , handlers,
> formatters etc, because you have to break down structured data ( objects )
> to name,value pairs.
> So what is the "worshipped" approach, when you need more than name=value
> pairs ?
JSON is one option: http://docs.python.org/library/json.html
Cheers,
Chris
--
http://blog.rebertia.com
Peter
> <snip>
>
>> So what is the "worshipped" approach, when you need more than name=value
>> pairs ?
>>
> JSON is one option: http://docs.python.org/library/json.html
>
>
>
seem to use this approach for improved conf file handling ( ipython,
pylons, etc ).
To me , the ipython way ( hybrid: ipy_user_conf.py and *.ini files )
seems to be the most comprehensive way amongst the larger apps I know
of, since it let you have a python coded file for what ever you might
want to do during initialization and have additional .ini files,
,possibily several in different locations, for simpler options in
name,value format.
Has anybody experiences with other tools that use this approach ?
Peter
Jorgen Grahn
> Peter wrote:
>> Hi
>> There seems to be several strategies to enhance the old ini-style
>> config files with real python code, for example:
>> Is there a strategy that should be prefered for new projects ?
...
> The .ini file is the simpliest solution, at least from the user point of
> view, no need to learn any python syntax.
Yeah. Use whatever your users expect, and deal with it. The language
you've happened to implement your stuff in should normally be
irrelevant to the users.
I wouldn't use .ini-style, but that's because I'm a Unix guy and they
remind me of brief and painful experiments with Windows 3.1.
Just remember to include support for commented-out lines.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
r0g
Yes, JSON is rapidly becoming a standard for stuff like this as it's
widely portable and less bulky than XML. It's the native format for
couchdb too which is nice if you want to replicate and share the
contents of your documents.
Roger.
Vinay Sajip
I don't know if you will find it relevant to your needs, but PEP 391
suggests an alternative method of configuring logging using dicts. The
use of dicts as the basic format (rather than Python code) allows for
some end-user flexibility and interoperability with other systems:
e.g. JSON, YAML and Python can all produce Python dicts.
Regards,
Vinay Sajip
Ben Finney
> JSON is one option: http://docs.python.org/library/json.html
YAML <URL:http://en.wikipedia.org/wiki/YAML> is another contender.
Compared to JSON, it is yet to gain as much mind-share, but even more
human-friendly and no less expressive.
Here are some discussions of YAML that can help you evaluate it:
<URL:http://www.ibm.com/developerworks/xml/library/x-matters23.html>
<URL:http://www.codinghorror.com/blog/archives/001114.html>
<URL:http://webignition.net/articles/xml-vs-yaml-vs-json-a-study-to-find-answers/>
--
\ “The Things to do are: the things that need doing, that you see |
`\ need to be done, and that no one else seems to see need to be |
_o__) done.” —Richard Buckminster Fuller, 1970-02-16 |
Ben Finney
Jonathan Gardner
> Chris Rebert <c...@rebertia.com> writes:
> > JSON is one option:http://docs.python.org/library/json.html
>
> YAML <URL:http://en.wikipedia.org/wiki/YAML> is another contender.
> Compared to JSON, it is yet to gain as much mind-share, but even more
> human-friendly and no less expressive.
>
> Here are some discussions of YAML that can help you evaluate it:
>
> <URL:http://www.ibm.com/developerworks/xml/library/x-matters23.html>
> <URL:http://www.codinghorror.com/blog/archives/001114.html>
>
>
YAML is far too complex to be useful. I played with it a while and
found the syntax even more confusing than XML, which is quite a feat.
Nicola Larosa (tekNico)
> There seems to be several strategies to enhance the old ini-style config
> files with real python code
> Is there a strategy that should be prefered for new projects ?
5) Use ConfigObj <http://www.voidspace.org.uk/python/configobj.html>,
by Michael Foord and yours truly. It uses an extension of the ini-
style config format. Sorry for the multiple brackets, my fault. :-)
--
Nicola Larosa - http://www.tekNico.net/
Ci sono paesi in cui un gesto violento se compiuto da un uomo su una
don-
na è punito più severamente: si chiama uguaglianza sostanziale,
compensa
la disuguaglianza di partenza. [...] Se vince la cultura dei
"vincenti"
le donne perderanno. Non fanno la guerra, in genere. È una perdita di
tempo: hanno altro da fare. - Concita De Gregorio, Novembre 2009