[Baypiggies] configuration parser using python modules?
Greg Rice
gregrice at gmail.com
Sat Jul 14 09:22:18 CEST 2012
Wouldn't a JSON be even better? Human-readable and cross-language, supports
hashes and arrays - seems perfect to me.
Greg Rice
MobiTV DevOps
On Jul 13, 2012 11:14 PM, <baypiggies-request at python.org> wrote:
>
> Send Baypiggies mailing list submissions to
> baypiggies at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.python.org/mailman/listinfo/baypiggies
> or, via email, send a message with subject or body 'help' to
> baypiggies-request at python.org
>
> You can reach the person managing the list at
> baypiggies-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Baypiggies digest..."
>
>
> Today's Topics:
>
> 1. configuration parser using python modules? (Aleksandr Miroslav)
> 2. Re: configuration parser using python modules? (Nam Nguyen)
> 3. Re: configuration parser using python modules? (James Tatum)
> 4. Re: configuration parser using python modules? (David Lawrence)
> 5. Re: configuration parser using python modules? (Ian Zimmerman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 Jul 2012 12:26:56 -0400
> From: Aleksandr Miroslav <alexmiroslav at gmail.com>
> To: baypiggies at python.org
> Subject: [Baypiggies] configuration parser using python modules?
> Message-ID:
> <CACcSE1xKgFQuni7VL=
uxgZgpfdvXNO_HUnsXYttKO1EukJcSRg at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> This may be obvious to people, but not to me, so I have to ask.
>
> Instead of using ConfigurationParser, why not have a configuration file
> be imported as a module, so this way, the variables could be part of the
> module's namespace.
>
> I know people have mentioned users running arbitrary code as a reason
> for why this should not be done, aside from this, is there any other
> reason? Is there a way to prevent users from running arbitrary code?
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 Jul 2012 11:18:38 -0700
> From: Nam Nguyen <bitsink at gmail.com>
> To: Aleksandr Miroslav <alexmiroslav at gmail.com>
> Cc: baypiggies at python.org
> Subject: Re: [Baypiggies] configuration parser using python modules?
> Message-ID:
> <CANG+ZTPeaFVmCVKY3JCgzRokkvET5z5j=
xc1MLHOqDRGp-CBWQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> I believe user experience is the major reason why Python module is
> usually not the recommended configuration mechanism. Regular users
> just don't want to deal with code if they can do away in some other
> form. INI, for example, is easy enough, and better organized then
> plain Python code.
> Nam
>
>
> On Fri, Jul 13, 2012 at 9:26 AM, Aleksandr Miroslav
> <alexmiroslav at gmail.com> wrote:
> > This may be obvious to people, but not to me, so I have to ask.
> >
> > Instead of using ConfigurationParser, why not have a configuration file
> > be imported as a module, so this way, the variables could be part of the
> > module's namespace.
> >
> > I know people have mentioned users running arbitrary code as a reason
> > for why this should not be done, aside from this, is there any other
> > reason? Is there a way to prevent users from running arbitrary code?
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 13 Jul 2012 11:53:39 -0700
> From: James Tatum <jtatum at gmail.com>
> To: Aleksandr Miroslav <alexmiroslav at gmail.com>
> Cc: baypiggies at python.org
> Subject: Re: [Baypiggies] configuration parser using python modules?
> Message-ID:
> <
CAM_-FGhFj5jqz_N+Xw7bE5Y4vyv5ViRfkB+ajXwikS5gsuueUw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> One of my pet peeves is using config files for things that really
> should be in code. It's a peculiar habit which seems very prevalent in
> areas like test frameworks where people often create massive XML
> configuration schemas. Not only is XML a terrible config file format
> (when the config file is meant to be written by humans), but using
> most any static config file is abandoning the expressiveness possible
> in code. Examples of configuration type things that are simple to do
> in code include conditionals, loops, variable substitution, and being
> able to encode any needed value or data type simply and easily.
>
> On Fri, Jul 13, 2012 at 9:26 AM, Aleksandr Miroslav
> <alexmiroslav at gmail.com> wrote:
> > This may be obvious to people, but not to me, so I have to ask.
> >
> > Instead of using ConfigurationParser, why not have a configuration file
> > be imported as a module, so this way, the variables could be part of the
> > module's namespace.
> >
> > I know people have mentioned users running arbitrary code as a reason
> > for why this should not be done, aside from this, is there any other
> > reason? Is there a way to prevent users from running arbitrary code?
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 13 Jul 2012 12:09:30 -0700
> From: David Lawrence <david at bitcasa.com>
> To: James Tatum <jtatum at gmail.com>
> Cc: baypiggies at python.org
> Subject: Re: [Baypiggies] configuration parser using python modules?
> Message-ID:
> <CAHGToM+Bp+2W+UEq1a9f=
bGY3vPSxrE2nQiEAX0yf-segYgRhg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I think James inadvertently summed up what should be in a config file.
> _Static_
> stuff. Things like API keys that rarely if ever change. Paths to logs,
> domains of
> external services. For those items, a non-language specific config file
> can make
> a single configuration usable by multiple services within the same
> ecosystem.
>
> Not every service/app may need everything in the file, but it makes it
easy
> to
> keep the settings consistent between maybe a web app written in Python,
> some
> pub-sub stuff written in JS on Node and maybe some desktop application
> (although
> in the case of deploying a desktop application, you may not want all your
> settings in
> the config in case you expose some internal sensitive info).
>
> In other cases, you may be supporting some legacy code in say Java, and
> slowly
> replacing parts in Python. Again, a non-language specific config file
> allows both
> the old and new code to have a consistent configuration.
>
>
> On Fri, Jul 13, 2012 at 11:53 AM, James Tatum <jtatum at gmail.com> wrote:
>
> > One of my pet peeves is using config files for things that really
> > should be in code. It's a peculiar habit which seems very prevalent in
> > areas like test frameworks where people often create massive XML
> > configuration schemas. Not only is XML a terrible config file format
> > (when the config file is meant to be written by humans), but using
> > most any static config file is abandoning the expressiveness possible
> > in code. Examples of configuration type things that are simple to do
> > in code include conditionals, loops, variable substitution, and being
> > able to encode any needed value or data type simply and easily.
> >
> > On Fri, Jul 13, 2012 at 9:26 AM, Aleksandr Miroslav
> > <alexmiroslav at gmail.com> wrote:
> > > This may be obvious to people, but not to me, so I have to ask.
> > >
> > > Instead of using ConfigurationParser, why not have a configuration
file
> > > be imported as a module, so this way, the variables could be part of
the
> > > module's namespace.
> > >
> > > I know people have mentioned users running arbitrary code as a reason
> > > for why this should not be done, aside from this, is there any other
> > > reason? Is there a way to prevent users from running arbitrary code?
> > > _______________________________________________
> > > Baypiggies mailing list
> > > Baypiggies at python.org
> > > To change your subscription options or unsubscribe:
> > > http://mail.python.org/mailman/listinfo/baypiggies
> > _______________________________________________
> > Baypiggies mailing list
> > Baypiggies at python.org
> > To change your subscription options or unsubscribe:
> > http://mail.python.org/mailman/listinfo/baypiggies
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
http://mail.python.org/pipermail/baypiggies/attachments/20120713/790ab22c/attachment-0001.html
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 13 Jul 2012 22:38:56 -0700
> From: Ian Zimmerman <itz at buug.org>
> To: baypiggies at python.org
> Subject: Re: [Baypiggies] configuration parser using python modules?
> Message-ID: <87fw8usxzj.fsf at foolinux.dyndns.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> David> app written in Python, some pub-sub stuff written in JS on Node
>
> In this case, JSON seems like an obvious choice for a config format :-P
>
> Personally, I try to just use eval(read(open(CONFFILE))) whenever
> remotely possible , guarded against surprises of course.
>
> The ConfigParser module is quite unpleasant IMO. Particularly because the
> natural structure to hold such information is either a dictionary or an
> object with named fields, but that's not what ConfigParser gives you.
>
> --
> Ian Zimmerman
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5 BD03 8A00 786C C6FF 61AD
> http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
> Rule 420: All persons more than eight miles high to leave the court.
>
>
> ------------------------------
>
> _______________________________________________
> Baypiggies mailing list
> Baypiggies at python.org
> To change your subscription options or unsubscribe:
> http://mail.python.org/mailman/listinfo/baypiggies
>
> End of Baypiggies Digest, Vol 81, Issue 7
> *****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/baypiggies/attachments/20120714/b1871aa8/attachment.html>
More information about the Baypiggies
mailing list