Keepin constants, configuration values, etc. in Python - dedicated module or what?

Rustom Mody rustompmody at gmail.com
Tue Sep 30 12:39:37 EDT 2014


On Tuesday, September 30, 2014 8:48:15 PM UTC+5:30, c... at isbd.net wrote:
> Rustom Mody wrote:
> > On Tuesday, September 30, 2014 5:18:31 PM UTC+5:30, Chris wrote:
> > > I would actually
> > > quite like to keep the configuration data separate from the code as it
> > > would simplify using the data at the 'home' end of things as I'd just
> > > need to copy the configuration file across.  This was why the database
> > > approach appealed at first as all I need to do is copy the database
> > > and everything is in there.
> > Of course
> > > Are there any better ways of doing this?  E.g. some sort of standard
> > > configuration file format that Python knows about? 
> > Umm this is getting to be a FAQ...
> > Maybe it should go up somewhere?
> > Yes there are dozens:
> > - ini
> > - csv
> > - json
> > - yml
> > - xml
> > - pickle
> > - And any DBMS of your choice
> > I guess Ive forgotten as many as Ive listed!!

> Yes, I know, I've found most of those.  I'm really asking for help in
> choosing which to use.  I think I can reject some quite quickly:-

>     xml - horrible, nasty to edit, etc. I don't like XML! :-)

Heh! Youve proved yourself a pythonista!

>     ini - doesn't work so well with lists/dictionaries (though possible)
>     csv - rather difficult to edit

Have you tried with comma=tab?

>     yml - front runner if I go for configuration files

Yeah my favorite as well

>     json - one of the most likely possibilities, but prefer yml

Seems to be most popular nowadays -- maybe related to being almost yaml
and in the standard lib

>     pickle - not user editable as I understand it

Well not in any reasonably pleasant way!

> What I'm really asking for is how to choose between:-

<snipped>

>     python - just keep config in the modules/classes, not easy to use
>     at 'both ends' (home and remote), otherwise quite simple

Can work at a trivial level.

As soon as things get a bit larger data and code mixed up is a recipe for mess up.



More information about the Python-list mailing list