Dealing with config files what's the options

Jorgen Grahn jgrahn-nntq at algonet.se
Sat Feb 26 21:07:53 EST 2005


On Fri, 25 Feb 2005 21:54:16 -0500, Tom Willis <tom.willis at gmail.com> wrote:
> On Fri, 25 Feb 2005 15:02:04 -0700, Dave Brueck
> <dave at pythonapocrypha.com> wrote:
>> Jorgen Grahn wrote:
...
>> > How about writing them in Python?
...
> I actually thought of this, and I was kind of on the fence due to the
> intended audience.
>
> I don't think it's too much to ask that they are comfy with the
> concept of variables. I mean, if it was a shell script they'd be at
> the top of the file anyway.
> 
> Then again I'm some what hesitant to help them make the connection
> that I'm giving them the ability to indirectly edit the code. Kind of
> like opening pandoras box. Once the figure out they can open any file
> (*.py) with notepad, there will be utter anarchy and I'll get the call
> at 4am that somethings wrong with the production data.

There's two issues there.

One is about hiding knowledge from the users.  I'm against that; this isn't
the middle ages. If they shoot themselves in the foot, that is /their/
problem, not yours. You support /your/ code, not whatever they hack together.
And with 99.999% certainty, they won't touch it.

The other is about the config file messing up the environment for your main
program. Seems hard to do by mistake -- you'd have to write endless loops or
import modules and modify them, or someting. I seem to recall that you can
evaluate a piece of code in a separate environment/sandbox -- maybe that's
the way to go?

(Personally, I try to avoid designs which need config files. If I /did/ need
one I'd steal the design from some well-known Unix program, because that's
my primary target, and I'd prefer not to lock myself into Python -- I might
want to rewrite the thing in C, or Perl, or ...)

/Jorgen

-- 
  // Jorgen Grahn <jgrahn@       Ph'nglui mglw'nafh Cthulhu
\X/                algonet.se>   R'lyeh wgah'nagl fhtagn!



More information about the Python-list mailing list