RE: Parsing environment variables in ConfigParser files

Discussion in 'Python' started by Robert Brewer, Dec 19, 2003.

  1. Does this snippet from ConfigParser.py give anyone any ideas on how to
    do this without subclassing? ;)

    class RawConfigParser:
    def __init__(self, defaults=None):
    self._sections = {}
    if defaults is None:
    self._defaults = {}
    else:
    self._defaults = defaults

    def defaults(self):
    return self._defaults


    >From the docs: "Default values can be specified by passing them into the

    ConfigParser constructor as a dictionary. Additional defaults may be
    passed into the get() method which will override all others."

    Let's not patch in a single use case when a simple generic solution
    already presents itself.


    Robert Brewer
    MIS
    Amor Ministries


    > -----Original Message-----
    > From: Peter Otten [mailto:]
    > Sent: Friday, December 19, 2003 10:21 AM
    > To:
    > Subject: Re: Parsing environment variables in ConfigParser files
    >
    >
    > Matthew Barnes wrote:
    >
    > > I'm considering submitting a patch for Python 2.4 to allow

    > environment
    > > variable expansion in ConfigParser files. The use cases for this
    > > should be obvious. I'd like to be able to specify

    > something like the
    > > following in a configuration file:
    > >
    > > [section_name]
    > > data_file=${HOME}/mydata.dat
    > >
    > > ...(where HOME=/home/matt) and have ConfigParser

    > automatically expand
    > > it to:
    > >
    > > [section_name]
    > > data_file=/home/matt/mydata.dat
    > >
    > > The change is pretty straight-forward, but I'm interested

    > in feedback
    > > on whether this is a good idea, what the syntax for environment
    > > variable references should look like (currently I'm thinking
    > > ${varname}), or whether there are any hidden complexities or
    > > backward-compatibility concerns.
    > >
    > > Matthew Barnes

    >
    > I think this can be easily achieved by subclassing the ConfigParser:
    >
    > >>> from ConfigParser import ConfigParser
    > >>> class ExpandingParser(ConfigParser):

    > ... def getexpanded(self, section, option):
    > ... import os
    > ... return self._get(section, os.path.expandvars, option)
    > ...
    > >>> p = ExpandingParser()
    > >>> p.read("expand.ini")
    > >>> p.get("paths", "mydir")

    > '$HOME/of/the/brave'
    > >>> p.getexpanded("paths", "mydir")

    > '/home/peter/of/the/brave'
    > >>>

    >
    > If you will bother with the library implementation at all, I
    > would prefer
    > this level of explicitness, i. e. a dedicated getexpanded() method in
    > ConfigParser, or alternatively a subclass that overrides
    > _get() to always
    > expand in the getXXX() methods. With both approaches you can
    > stay safely
    > away from backwards compatibility problems.
    >
    > Peter
    >
    >
    >
    >
    >
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
    >
    Robert Brewer, Dec 19, 2003
    #1
    1. Advertising

  2. Robert Brewer

    Peter Otten Guest

    Robert Brewer wrote:

    > Does this snippet from ConfigParser.py give anyone any ideas on how to
    > do this without subclassing? ;)
    >
    > class RawConfigParser:
    > def __init__(self, defaults=None):
    > self._sections = {}
    > if defaults is None:
    > self._defaults = {}
    > else:
    > self._defaults = defaults
    >
    > def defaults(self):
    > return self._defaults


    The RawConfigParser does not do interpolation.

    >>From the docs: "Default values can be specified by passing them into the

    > ConfigParser constructor as a dictionary. Additional defaults may be
    > passed into the get() method which will override all others."


    I would have expected a quote with at least one "%" character ;)

    If you want to allow both $HOME and %(HOME)s style interpolation, overriding
    ConfigParser.get() is the solution with the least effort. Both replacements
    can then be applied orthogonally. Environment variable names are not
    controlled by your application, so I would oppose injecting them into the
    default section.

    > Let's not patch in a single use case when a simple generic solution
    > already presents itself.


    I tend to agree.

    Peter
    Peter Otten, Dec 19, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew Barnes
    Replies:
    6
    Views:
    1,254
    Skip Montanaro
    Dec 21, 2003
  2. Replies:
    5
    Views:
    650
  3. Replies:
    3
    Views:
    427
  4. Andrew Z.

    Parsing error for ConfigParser

    Andrew Z., Sep 23, 2010, in forum: Python
    Replies:
    1
    Views:
    799
    Philip Semanchuk
    Sep 23, 2010
  5. pikespeak
    Replies:
    1
    Views:
    505
    Rodrick Brown
    Oct 15, 2010
Loading...

Share This Page