[tor-bugs] #4913 [Stem]: Add stem.util.conf.Config.save()
    Tor Bug Tracker & Wiki 
    torproject-admin at torproject.org
       
    Mon Jan 16 16:09:01 UTC 2012
    
    
  
#4913: Add stem.util.conf.Config.save()
-------------------------+--------------------------------------------------
 Reporter:  gsathya      |          Owner:  atagar        
     Type:  enhancement  |         Status:  needs_revision
 Priority:  normal       |      Milestone:                
Component:  Stem         |        Version:                
 Keywords:               |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------
Comment(by atagar):
 > I'm not sure I follow. Where is this from?
 First line after the pydocs in...
 https://gitweb.torproject.org/user/gsathya/stem.git/commitdiff/4ba49e08ba1d4b07fbb3af87652cd11b3d9fdb9d
 > Yeah, I wanted to do --
 > for entry in sorted(self.iterkeys()):
 Oh, good catch - we should use sorted() instead of sort in this case...
 > So we have a config file that has...
 Ahh, I see. This is a problem with the set() method, not with save. In the
 example that you give the user is expecting the set() call to overwrite
 the configuration value rather than add a new one.
 On reflection, what if we changed set() to...
 {{{
 def set(self, key, value, overwrite = True):
   """
   Sets the given key/value configuration mapping, behaving the same as if
 we'd
   loaded this from a configuration file.
   Arguments:
   key (str)           - key for the configuration mapping
   value (str or list) - value we're setting the mapping to
   overwrite (bool)    - replaces our current configuration mapping if
 True,
                         otherwise it's appended to the configuration
   """
 }}}
 This would allow the more intuitive usage that you're expecting.
 > ACK! I just saw that you passed Multiple=True to Config.get_value(), in
 your latest commit. Now with the above example, when we call Config.save()
 we'd be storing
 >
 > login.password foo bar
 >
 > Right?
 Not quite, we'd store...
 {{{
 login.password foo
 login.password bar
 }}}
 This seems like the right behavior if we *mean* for password to have
 multiple values. Again, if we wanted it to have a single value then that's
 more a problem with set().
 > Please Ignore. I think we can close this ticket and save me from saying
 anything else?
 Don't worry about it, we're all human. :)
-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4913#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
    
    
More information about the tor-bugs
mailing list