Re: Recommended new way for config files

2010-02-25 Thread Nicola Larosa (tekNico)
Peter wrote:
 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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-19 Thread Jonathan Gardner
On Jan 8, 2:54 pm, Ben Finney ben+pyt...@benfinney.id.au wrote:
 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
     
 URL:http://webignition.net/articles/xml-vs-yaml-vs-json-a-study-to-find-a...



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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-08 Thread Jorgen Grahn
On Thu, 2010-01-07, Jean-Michel Pichavant wrote:
 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   .
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-08 Thread r0g
Chris Rebert wrote:
 On Thu, Jan 7, 2010 at 10:19 AM, Peter vm...@mycircuit.org wrote:
 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.
 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
 
 Cheers,
 Chris
 --
 http://blog.rebertia.com


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.
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-08 Thread Vinay Sajip
On Jan 7, 8:12 pm, Peter vm...@mycircuit.org wrote:
  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

 Thanks, didn't think about that, although most of the apps I know don't
 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

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
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-08 Thread Peter

On 01/08/2010 03:57 PM, r0g wrote:

Chris Rebert wrote:
   

On Thu, Jan 7, 2010 at 10:19 AM, Petervm...@mycircuit.org  wrote:
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.
   

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

Cheers,
Chris
--
http://blog.rebertia.com
 


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.
   
Excellent, thanks , have to check that out. Any experience with yaml 
http://yaml.org/ ?

Peter
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-08 Thread Ben Finney
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

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
-- 
http://mail.python.org/mailman/listinfo/python-list


Recommended new way for config files

2010-01-07 Thread Peter

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
--
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread Jean-Michel Pichavant

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


--
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread Lie Ryan

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.
--
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread Robert Kern

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

--
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread Peter

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




--
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread Chris Rebert
On Thu, Jan 7, 2010 at 10:19 AM, Peter vm...@mycircuit.org wrote:
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.
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

Cheers,
Chris
--
http://blog.rebertia.com
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: Recommended new way for config files

2010-01-07 Thread 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


   
Thanks, didn't think about that, although most of the apps I know don't 
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
--
http://mail.python.org/mailman/listinfo/python-list