Update field with ConfigParser -Python-

Question

I thought that the set method of ConfigParser module updates the field given, but, it seems that the change remains only in memory and doesn't get into the config file. Is it a normal behaviour?

I have also tried the write method, but what I got was another replicated section which by so far is not what I want.

Here is a specimen which represents what I'm doing:

import sys
import ConfigParser 

   if __name__=='__main__':    
   cfg=ConfigParser.ConfigParser()
   path='./../whatever.cfg/..'
   c=cfg.read(path)
   print cfg.get('fan','enabled')
   cfg.set('fan','enabled','False')       
   c=cfg.read(path)
   print cfg.get('fan','enabled')

Solution 1

1. open the config file
2. read the content using ConfigParser
3. close the file
4. update the config, in memory now
5. open the same file with w+
6. write the updated in-memory content to the file
7. close the file

Solution 2

from ConfigParser import SafeConfigParser
parser = SafeConfigParser()
parser.read('properties.ini')
dhana = {'key': 'valu11'}
parser.set('CAMPAIGNS', 'zoho_next_campaign_map', str(dhana))
with open("properties.ini", "w+") as configfile:
    parser.write(configfile)

Solution 3

Yes, it is normal that set operates on the information in memory rather than on the file from which the information was originally read.

write ought to be what you want. How exactly did you use it, what exactly did it do, and how did that differ from what you wanted?

Incidentally, you should generally be using ConfigParser.SafeConfigParser rather than ConfigParser.ConfigParser unless there's a specific reason for doing otherwise.

Moving forward with Python 3.x SafeConfigParser will be merged/renamed as ConfigParser so SafeConfigParser will eventually be deprecated and phased out.

Solution 4

I ran into the same issue and figure out that this worked for me:

def update_system_status_values(file, section, system, value):
    config.read(file)
    cfgfile = open(file, 'w')
    config.set(section, system, value)
    config.write(cfgfile)
    cfgfile.close()

1) Read it

2) Open it

3) Update it

4) Write it

5) Close it

View more solutions

Comments

[Francisco]

Here`s how I'm using write: with open(self.path,'a') as configfile: self.cfg.write(configfile) write(self.cfg)

[Gareth McCaughan]

Why are you appending to the file instead of replacing it?

[Francisco]

Because of common sense, I think. Why have to rewrite the whole file if you only want to change a single field?

[Gareth McCaughan]

Suppose the single field is defined at the start of the file (or, in fact, anywhere other than the end). Then your choices are: (1) rewrite the file or (2) append to the file and accept the redundancy. Option 2 gets very bad if the config is repeatedly changed, so option 1 it is. If that goes against your common sense, then you might want to consider the possibility that your common sense needs a little adjustment.

[Francisco]

I like your last phrase. LOL.

[Francisco]

Anyway, opt 2 is not an option either. I will go with the first one. But It surprises me a lot that there isn't a, lets say, 'commit or update' method where you can relay your updates of the config file. Low eficiency, I would risk to say.

[Gareth McCaughan]

Really, how often does a config file like this need updating? If it's happening often, the file will be in the OS's cache and rewriting the whole thing will take less than a millisecond on a typical machine. If it's not happening often, who cares about a few ms of extra time? So unless you're updating the config file, say, 100 times per second, I don't see that there's a problem here. (And if you are, you should do something else instead.)

[Francisco]

Right. I see your point. In fact, this update in my config file is a consecuence of a command given by the user. So, pushing to the limit, can five or ten times a day. The overhead is present, but is not critical. If there's no way of update a single value, I will have to rewrite it all like the rest of the world who use ConfigParser

[humble_wolf]

why do you think step 3/5 is needed ? I guess this might produce inconsistencies if two processes are writing the same file at almost same time.