Prev: from datetime.datetime import today not working. python2.6.4on windows
Next: ANN: Pymazon 0.1.0 released!
From: Peter on 7 Jan 2010 11:10
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


Is there a strategy that should be prefered for new projects ?

thanks
peter
From: Lie Ryan on 7 Jan 2010 11:30
On 1/8/2010 3:10 AM, Peter wrote:
> Is there a strategy that should be prefered for new projects ?

The answer is, it depends.
From: Jean-Michel Pichavant on 7 Jan 2010 11:32
Peter wrote:
> 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
>
>
> Is there a strategy that should be prefered for new projects ?
>
> thanks
> 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


From: Robert Kern on 7 Jan 2010 11:38
On 2010-01-07 10:10 AM, Peter wrote:
> 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

From: Peter on 7 Jan 2010 13:19
Thanks for your answer, let me be more precise:

> 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




 |  Next  |  Last
Pages: 1 2 3
Prev: from datetime.datetime import today not working. python2.6.4on windows
Next: ANN: Pymazon 0.1.0 released!