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